RE: [reSIProcate] Multi-threaded Stack

[Scott Godin <slgodin@xxxxxxxxxxxx>]

"If running multithreaded why do we need to call process()? Shouldn't the
thread simply run and process the message on its, own and invoke the
callback and therefore send the response?"

I haven't actually used the multi-threading stuff - but here is my
understanding:

Setting the Stack to be multithreaded, by doing the following:
      std::auto_ptr<SipStack> sipStack(new SipStack(true));
      DialogUsageManager* dumUas = new DialogUsageManager(sipStack);
will cause each of the transports to run in their own threads.

Calling dum->run() - will cause the entire core stack (not DUM) to run in
it's own thread.  This means that only DUM layer and the application layer
(your code) will run in the main thread - assuming your application only has
one thread.  

You can call dum->run() without having the multi-threaded stack.  This means
the stack runs in it's own thread, but the transports all run from this same
thread.

dum->process() - is still required because the DUM layer is running in your
applications thread and requires time to do it's processing.  The important
thing to remember here, is that DUM is not part of the core stack.

To summarize - these are the following threading architectures:
Single Threaded - application, dum, stack and transports all run in the same
thread.  This is how BasicCall works.

Separate Stack Thread - application and dum run in main thread, stack and
transports run in another thread.

Separate Stack and Transport Threads - application and dum run in main
thread, each transport runs in a separate thread and the core stack itself
runs in a separate thread.

NOTE:  There is no threading protection in DUM if you application itself is
multi-threaded.  You MUST provide your own protection if you plan on calling
dum->process or and/or other DUM API's from different threads.

Hope this helps.

Scott

-----Original Message-----
From: Graham Pearson [mailto:pearson@xxxxxxxxxxxxxxxxxx] 
Sent: Friday, March 04, 2005 11:35 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Multi-threaded Stack

Can anybody help me understand running the stack in multithreaded mode. I've
been unable to find any of the samples running in multithreaded mode. All
the samples work fine for me singlethreaded. I'm using the BasicCall sample
and have changed the DialogUsageManager/SipStack to be multithreaded as
follows:

      std::auto_ptr<SipStack> sipStack(new SipStack(true));
      DialogUsageManager* dumUas = new DialogUsageManager(sipStack);

I've also read the following comments in the DialogUsageManager.hxx:

     // Runs the SipStack in its own StackThread. call process() from the
application
      void run();

      // Call this version of process if you are running the sipstack in its
own
      // thread. you must call run() before calling process()
      bool process();

      // Call this version of process if you want to run the stack in the
      // application's thread
      void process(FdSet& fdset);

In the sample the client sends on OPTION message request and the server
replies with a response. When running this in multithreaded I can see that
the transport layer does receive the message but the
ServerOutOfDialogReq::answerOptions callback does not get triggered and
therefore no response message is sent back to the client.

Also, I dont understand why it says "Call this version of process if you are
running the sipstack in its own
      // thread. you must call run() before calling process()"
      bool process();

If running multithreaded why do we need to call process()? Shouldn't the
thread simply run and process the message on its, own and invoke the
callback and therefore send the response?

Thanks in advance!

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel