reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Dum threading

Hi,

I have the same dilemma. My approach is to queue my own type of events inside the Handlers' callbacks. This will require to store the callback information (Handles, Sip messages, etc...) in these events. These events will be processed asynchronously by the application threads.

Can I assume the callbacks are designed to work in this mode ? Is there another way ?
Can the same be assumed on dum manager classes (such as ServerAuthManager) ?

Thanks,
Elberg Meir.

On 9/29/05, Micky Kaufmann <micky@xxxxxxxxxxx> wrote:

Hi all,

 

I looked at the DUM Wiki on DUM threading - http://warsaw.sjc.purplecomm.com/wiki/index.php?title=DUM_Threading.

I'm missing two things there – 'Howto' for thread models and a way to separate the application threads from the dum callbacks.

I.e. I wish to handle the dum callbacks in a cpu (thread) different from the thread of the dum stack itself, since the callback code may consume too much time.

 

Did anyone implement something similar?

 

Micky Kaufmann

 


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel