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