[reSIProcate] thread safe

[Scott Godin]

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/46aef8fb/attachment.htm>