Re: [Linphone-developers] session_set_select problem

[Filipp . Andjelo]

Hi Vadim,

I've implemented the timed_select function,
but now I see, that the problem is deeper, as I thought. 
session_set_select() doesn't wait on
ortp_cond_wait() for long. It gets the signal after at least 10ms 
(POSIXTIMER_INTERVAL) from the scheduler.
So the select() is really stucking in the while(1) loop
and not on cond_wait. The session_set_select()
is a poll, but not a select function, it polls each 10ms
to check the bitmask an goes sleeping
till the next signal from the scheduler arrives.
I can't do here anything with cond_timed_wait(),
but I've implemented a dirty workaround for now. In
the feature, a better solution should
be found. Scheduler should send a cond_signal only if internal 
bitmask was changed, and not on every
loop, as it is now. Say, what do you think about my conclusion.
I'm a newbe here, what do you think,
should I notify Simon about this problem by another way, or does 
he read sooner or later this mail by
himself? 

Greetings,
Filipp.




address@hidden
schrieb am 19.10.2009 15:26:58:

> address@hidden wrote: 
> 
> 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 

> 
> Hi Filip,
> 
> I think that Simon will accept the ..._timed_select into  oRtp,
 as 
> it seems a useful function, but you should ask him....
> 
> Thanks
> Vadim
> 
> 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
> > >   
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers

sessionset.h.diff
Description: Binary data

sessionset.c.diff
Description: Binary data

port.h.diff
Description: Binary data

port.c.diff
Description: Binary data