Re: [reSIProcate-users] Mutli-threading reSiprocate
Answers inline...
On Wed, Dec 2, 2009 at 5:50 AM, Meenatchy Annamalai
<meenatchy.annamalai@xxxxxxxxxxxxxxxxxxxx> wrote:
> Hi,
>
> I am going through the reSiprocate code and trying to understand the
> threading model.
>
> Can you confirm that the stack is a single thread. In the architectural
> diagram (http://svn.resiprocate.org/viewsvn/resiprocate/main/resip/stack/doc/ResipArchitecture.pdf?view=co), it
> shows multiple threads (separate threads for transports, Transaction FSM &
> SipOject).
A long while back the resiprocate transports were capable of running
their own threads. However this was not maintained and was eventually
removed. Today the SipStack runs in one thread only.
> Can we run mutiple TUs on a same stack and each TUs running as a separate
> thread?
Yes that is possible. The stack communicates with TU's solely through
a FIFO queue.
> DUM threading model (http://www.resiprocate.org/DUM_Threading) states "A
> class called DumThread is in the works. This will allow you to run all of
> resiprocate in it's own thread (or threads)". Can some one clarify following
> understanding is right.
>
> i. DumThread Class gets a message from FIFO and processes it in a loop. By
> having different message filter rules one can have different threads
> processing different messages using multiple DUMThreads.
Not quite. DUM itself can only run in one thread (despite the wording
on the wiki, which I will correct). DUM is a TU - if you run another
TU along side DUM with different message filter rules, then it is
capable of running in it's own thread. You won't be able to use
DumThread for this, but you can create something similar to DumThread
for your new TU.
> ii. If we want to have multiple threads processing different calls (i.e same
> message filter rules), can this be achieved with the same DumThread Class??
No - this is not possible.
> 4. what is the call rate with the current threading model?
It should be noted that the application has control over the threading
model to a degree. It can decide if the stack, dum and itself runs in
separate threads, or the whole thing is run in just one thread. So
the performance is dependent on that as well as the speed of the host
CPU(s).
I've dug up an old post on stack performance itself, that may help you though:
http://list.resiprocate.org/archive/resiprocate-devel-old/msg01955.html
> Thanks & Regards,
> Meenatchy Annamalai
> Consultant
>
> Prithvi Information Solutions Ltd
> 10Q3A1, Cyber Towers
> HITEC City, Madhapur
> Hyderabad - 500 081
> Desk: +091 - 040 - 66846019 XT: 347
> http://www.prithvisolutions.com
>