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
> >
|