linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] session_set_select problem


From: Frédérik Rouleau
Subject: Re: [Linphone-developers] session_set_select problem
Date: Wed, 4 Nov 2009 17:16:36 +0100

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


Attachment: sessionset.c.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]