Re: [reSIProcate] thread safe

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

…

 

From: Ira Kadin [mailto:ikadin@xxxxxxxxxxx]
Sent: Tuesday, September 05, 2006 11:55 AM
To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx]
Sent: Tuesday, September 05, 2006 6:20 PM
To: Ira Kadin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ira Kadin
Sent: Tuesday, September 05, 2006 2:28 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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