Re: [reSIProcate-users] clientSubscription NOTIFY problem
Hi Scott!
I just modified the basicRegister example to start a DumThread and a
InterruptableStackThread. I have removed all stack.process(fdset) and
clientDum.process() calls and it still works fine.
From the application, I still call DUM methods, e.g.
SharedPtr<SipMessage> regMessage = clientDum.makeRegistration(userAor);
clientDum.send( regMessage );
just as before.
The Wiki mentions that the application may need to provide its own mutex
to protect access to DUM. Is this only needed when the application
itself is multithreaded or also if the application is just single threaded?
For example, although the application is single threaded, what happens
if DUM calls my ClientRegistrationHandler and I call some DUM methods
from within the Handler (which might happen at the same time the
application calls some DUM methods)?
Thanks
Klaus
Am 09.06.2010 18:00, schrieb Scott Godin:
There is no "out-of-box" threading class that will handle both the stack
and dum - but it shouldn't be hard to create on if you like. Otherwise,
you will need both DumThread and InterruptableStackThread.
Scott
On Wed, Jun 9, 2010 at 11:54 AM, Klaus Darilion
<klaus.mailinglists@xxxxxxxxx <mailto:klaus.mailinglists@xxxxxxxxx>> wrote:
Hi Scott!
Am 08.06.2010 19:32, schrieb Scott Godin:
Further, is there a mode to let stack/dum create a thread
itself for
internal processing (so that I do not need an event loop in the
application, but wait for callback events)?
There is a pretty detailed wiki page on all this stuff:
http://www.resiprocate.org/DUM_Threading
Not sure if I got it right: I do not care about if dum and stack use
the same thread or a different one - I just want that all the SIP
stuff is happening asynchronously independent from the application's
thread.
Will using DumThread solve my issues or do I have to use StackThread
(or InterruptableStackThread) too?
Thanks
Klaus