Re: [Linphone-developers] session_set_select problem

[Simon Morlat]

Thanks it is now merged into svn/git trees.

Simon

Le mercredi 4 novembre 2009 17:16:36, Frédérik Rouleau a écrit :
> Hum it is always after sending a patch that I saw a better solution...
> 
> This one is better as we do not loose time for nothing in ortp_cond_wait
> 
>   while(1) {
>         ....
>         remainingTime -= sched->timer_inc;
>         if (remainingTime<=0)
>             break;
>         ortp_cond_wait(&sched->unblock_select_cond,&sched->lock);
>     }
> 
> 
> 2009/11/4 Frédérik Rouleau <address@hidden>
> 
> > Hi All,
> >
> > I propose the following patch. It adds a kind of timeout to
> > session_select of scheduler granularity but it is better than nothing.
> >
> > Fred,
> >
> > On Mon, Oct 26, 2009 at 10:00 AM, Simon Morlat 
<address@hidden>wrote:
> >> Hi All,
> >>
> >> I recognize scheduled mode isn't optimized at all.
> >> I recommend anyone building a performance critical project (such as
> >> running
> >> hundred of calls), to avoid scheduled mode and instead use its own
> >> scheduling
> >> mechanism, ortp being used in non-scheduled, non blocking mode.
> >> See for example as it is used in mediastreamer2, where mediastreamer2
> >> provides
> >> its own ticking mechanism, and oRTP being there just to compose/send 
> >> and recv/parse RTP packets.
> >>
> >> Simon
> >>
> >> Le mardi 20 octobre 2009 15:44:11, Vadim Lebedev a écrit :
> >> > H Fillip,
> >> >
> >> > I do aggree that rtp sheduling stuff could be optimized to avoid
> >> > polling  and
> >> > to wake concerned threads only when there is a real need....
> >> >
> >> > However it a BIIIIG effort to change it....
> >> > I think that in your case it could be simpler to avoidl RTP secheduled
> >> > mode at all
> >> > and write your owne minischeduler which does 'select'   and  call on
> >> > rtp_sesion_rtp/rtcp_recv when needed
> >> >
> >> >
> >> >
> >> >
> >> > Thanks
> >> > Vadim...
> >> > P.S.  Simon what do yout think?
> >> >
> >> > address@hidden wrote:
> >> > > 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.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > linphone-developers-bounces+filipp.andjelo=rohde-schwarz.com@
> >>
> >> nongnu.org
> >>
> >> > > 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
> >>
> >> _______________________________________________
> >> Linphone-developers mailing list
> >> address@hidden
> >> http://lists.nongnu.org/mailman/listinfo/linphone-developers
>