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

RE: [reSIProcate] DUM and Thread Safety


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@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Scott Godin
Sent: Wednesday, July 14, 2004 2:15 PM
To: 'Derek@xxxxxxxx'
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx

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