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