[reSIProcate] thread safe

[Ira Kadin]

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.
 
The second solution - could you give me an example how to end a call
with dum->post.
 
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/df0d39b8/attachment.htm>