[reSIProcate] thread safe

[Kovar, William (Bill)]

Scott,
 
Is there any special reason why you are using the AppDialogSetHandle to
end the call in your example below??
 
Can the handle be the InviteSessionHandle ??
 
 
Bill Kovar
bkovar at avaya.com
Avaya, Inc.
(732) 852-2609
 


  _____  

	From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
Scott Godin
	Sent: Tuesday, September 05, 2006 12:08 PM
	To: Ira Kadin; resiprocate-devel at list.sipfoundry.org
	Subject: Re: [reSIProcate] thread safe
	
	

	...

	 

	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/20070112/a843da52/attachment.htm>