[reSIProcate] thread safe

[Scott Godin]

...

 

From: Ira Kadin [mailto:ikadin at Airspan.com] 
Sent: Tuesday, September 05, 2006 11:55 AM
To: Scott Godin; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] thread safe

 

 

So for the first solution I can't use  dumThread - or will have to make
a changes in DumThread  to mutexing around InternalProcess() . And it
will be one mutex for all calls.

 

[Scott] right

 

The second solution - could you give me an example how to end a call
with dum->post.

[Scott] Something like the following....

class AppDialogSetEndCommand : public DumCommand
{

   AppDialogSetEndCommand(AppDialogSetHandle h) : mHandle(h) {}

  executeCommand()

{ 

   If(mHandle.isValid()) 

   { 

      mHandle->end();

   }

private:

   AppDialogSetHandle mHandle;

};

 

AppDialogSetEndCommand* cmd = new
AppDialogSetEndCommand(ads->getHandle);

Dum->post(cmd);

 

thanks a lot

 

Irena

 

________________________________

From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: Tuesday, September 05, 2006 6:20 PM
To: Ira Kadin; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] thread safe

The easiest place to provide mutexing is around the calls to process()
and any other api calls you call from a different thread.  This requires
no changes to the core code.

 

The alternative approach, using DumCommand - the only call you make from
another thread is dum->post() which is thread safe.  I'm not sure what
you don't understand.  Calling end() does more than just queue a destroy
message.

 

DumV2 has been started - but hasn't been worked on in a few months.
There is no timeline for it.  It is planned to be thread safe.

 

From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Ira
Kadin
Sent: Tuesday, September 05, 2006 2:28 AM
To: resiprocate-devel at list.sipfoundry.org
Subject: [reSIProcate] thread safe

 

Thanks everybody who answered me on GW application question.

 

We want to develop the application which can handle 400-500 simultaneous
calls. So I think we will need to run dum and sip stack in separate
threads. As dum is not thread safe, I guess we have to  put locking
object in ApplDialog class and use it in all callbacks (onConnected,
onProvisional, etc..) and functions, like DialogUsageManager::end(),
DialogUsageManager::accept()   called from different application
threads. Is it a right solution ? I don't understand the second advise -
use DialogUsageManager::post() - because for this solution I have
prepare SipMessage myself (meaning - duplicate code in end() function.

 

Is it any plan to make Dum thread safe ?

 

thanks

 

Irena

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060905/fff6f3e4/attachment.htm>