| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
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@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 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 |