Re: Re: [Linphone-developers] session_set_select problem

[Filipp . Andjelo]

Hi Vadim,

I thought about that sulution already,
but it's not so clean, you know. All sessions are managed by another class
SessionManager. It gets a request to
add or remove a session by other instance. On remove, it would now just

delete the one from the list/memory,
without to know, that the Session is still used by Sende/Receiver.
May be I could workaround that problem,
but if MemoryManager gets a request to close the session, it should
do so, this condition is in the reqirements
and I can't change it. 

I think, I can't solve it without a
timeout, but I don't want to get away from the standard oRTP Library, do
you think
it is possible to integrate the session_set_timed_select
function in the lib, if I'll get it implemented?

Greetings,
Filipp


Vadim Lebedev <address@hidden> schrieb am
16.10.2009 18:13:26:

> Filipp:
> 
> 
> How about following to avoid blocking while holding the lock?
> 
> class Sender : Thread {         
>         send() { 
>                 smutex.lock();
<-- Session list must stay unchanged,
> untill select/send is done
>              tmpsessions = sessions.copy();
>                 smutex.unlock();
>                    
 
>                 for each session
in tmpsessions { 
>                    
    session_set_set(sset, session)    <-- recognize
this?
>                 } 
> 
>                 session_set_select(NULL,
sset, NULL);  <-- This one 
> blocks, if s.t. is not ok 
> 
>                 for each session
in tmpsessions { 
>                    
    if (session_set_is_set(sset, session) ) { 
>                    
            send packet; 
>                    
    } 
>                 }    
    
>         
>         
>         }         
> } 
> 
> 
> 
> 
> address@hidden wrote:
> 

> 
> Thank you very much for the fast answer, 
> 
> your suggestion wuld help me I think. I don't want to change 
> standard oRTP Code, but may be I'll reimplement the function 
> directly in my code. And about the mutex, I've not written about 
> internal oRTP one, but about one in my code. I made a C++ 
> encapsulation of oRTP, see the pseudo Code, may be you have an idea:
> 
> Mutex smutex;                <--
oRTP based mutex 
> List sessions;                <--
list of oRTP sessions 
> SessionSet sset;         <-- from oRTP 
> 
> class Manager { 
> 
>         add(session) { 
>                 smutex.lock();
>                 sessions.add(session);
>                 smutex.unlock();
>         } 
> 
>         remove(session) { 
>                 smutex.lock();
>                 sessions.remove(session);
>                 smutex.unlock();
>         } 
> } 
> 
> class Sender : Thread {         
>         send() { 
>                 smutex.lock();
<-- Session list must stay unchanged,
> untill select/send is done 
>                 for each session
in sessions { 
>                    
    session_set_set(sset, session)    <-- recognize
this?
>                 } 
> 
>                 session_set_select(NULL,
sset, NULL);  <-- This one 
> blocks, if s.t. is not ok 
> 
>                 for each session
in sessions { 
>                    
    if (session_set_is_set(sset, session) ) { 
>                    
            send packet; 
>                    
    } 
>                 }    
    
>         
>                 smutex.unlock();
        <-- if select blocks, this 
> is never reached and whole program is blocked 
>         }         
> } 
> 
> Receiver is just like Sender. If one of the sending/receiving no 
> sessions can be added or removed. What do you think about it? 
> May be I did not understand the non blocking mode of oRTP right, but
> as I see, you don't have any possibility to make dynamic 
> list of sessions. 
> 
> Best regards and thank you very much, 
> Filipp 
> 
> 
> Vadim Lebedev <address@hidden> schrieb am 15.10.2009 19:33:34:
> 
> > Fillip,
> > 
> > First of all,  the session_set_select  does lock the
mutex for only 
> > breif moment  because
> > the call ortp_cond_wait (which is mapped to pthread_cond_wait
on 
> > linux)  unlocks the mutex before entering the wiat state.
> > 
> > If you still need a timed wait what you can do is following:
> > 
> > in include/ortp/port.h  add
> > #define ortp_cond_timedwait pthread cond_timedwait
> > 
> > in the  src/sessionset.c
> > 
> > create a new function  session_set_timedselect  which
is EXACTLY  
> > like session_set_wait but has a timespec pointer...
> > in this function replace the call to ortp_cond_wait to ortp_cond_timedwait
> > 
> > 
> > Thanks
> > Vadim
> > 
> >    
> > address@hidden wrote: 
> > 
> > Hello, 
> > 
> > I've decided to use oRTP library for a large RTP session manager
and
> > now stucking. I have a dynamic list of rtp sessions. Because
of the 
> > rich number of sessions, own thread for each one is not a solution,
> > so I wanted to use session_set_select to send/recv data. I'm
using a
> > mutex to handle the critical section. Every time a 
> > session_set_select called, the list of running sessions is locked
> > and no additional sessions can be added/removed, after 
> > select/send/recv is done Mutex will be unlocked and new sessions
can
> > be added to the list. In this time no send/recv is possible.
So far 
> > is the theory, but if all running sessions are permanently not
ready
> > to send/recv, then session_set_select blocks forever. No send,
no 
> > receive, no open new session or close running one. 
> > 
> > The "normal" select  (based on filedescriptors)
has an extra 
> > argument for timeout, to unblock the thread. how can it be done
> > using oRTP. In current situation I don't see any possibility
to have
> > dynamic list of sessions, it works if the count of sessions is
known
> > from the beginning and is always constant. Shouldn't 
> > session_set_select(...) be extended by additional argument for
> > timeout as select() is? Or is there any other solution. 
> > 
> > Fast help is very appreciated. 
> > Thx, 
> > Filipp 
> > 
> > 
> > _______________________________________________
> > Linphone-developers mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/linphone-developers
> >