[reSIProcate] DUM and Thread Safety

[Derek MacDonald]

Hi Scott,

 DUM is single threaded, and this won't be changing anytime soon.  With the
way the app interacts w/ the usages, there are far to many race conditions
that would need to be handled.  If you want to use DUM from multiple
threads(including the thread that calls process) you will have to do your
own locking.

 Derek
    -----Original Message-----
    From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org]On Behalf Of Scott
Godin
    Sent: Wednesday, July 14, 2004 2:15 PM
    To: 'Derek at xten.com'
    Cc: resiprocate-devel at list.sipfoundry.org
    Subject: [reSIProcate] DUM and Thread Safety


    Derek,



    Has there been much though put into thread safety aspects of the DUM?



    I don't use the stack in Multi-threaded mode - but I am using 1 thread
to run the select/process loop and other threads (ie. One per SIP/RTP port)
that can call the send/end/makexxx methods of the various Session objects
(just Invite session for now).  I am concerned that some of these calls,
could end up deleting memory that may be in use by the main process loop.



    For example:  What if I call send on ClientInviteSession to send a
CANCEL message - this deletes the ClientInviteSession object itself (ie.
delete this).  But what if the main thread is processing an inbound message
destined for the ClientInviteSession at the same time and is accessing the
session object?



    What assumptions are made by the DUM as far as threading is concerned?
What is the final goal as far as threading is concerned?



    Thanks,







    Scott Godin

    Research and Development

    Computer Talk Technology

    slgodin at icescape.com

    905-882-5000 and 'Say my name' or x127


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20040714/b8fa65e6/attachment.htm>