[reSIProcate] Dum threading

[Meir Elberg]

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 at proxy.co.il> 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 at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050929/54e55468/attachment.htm>