[reSIProcate] dum-based client instability - Application Timer not thread safe

Jason Fischl jason at purplecomm.com
Fri Oct 29 17:34:39 CDT 2004


Hi all,

I think I finally figured out why our dum-based client is unstable. 
Shortly after we implemented dum, ApplicationTimers were added to 
resiprocate. These use the same TimerQueue that the stack uses. 
Unfortunately, the TimerQueue assumes that all timers are inserted from 
the same thread - specifically from the TransactionState. So when the 
application/dum (in our case running in a separate thread) calls 
SipStack::post, this is an unsafe call.

Here are a few possible solutions:
1) mutex around mTimers access
2) when posting ApplicatioMessage in future (timers), put in a fifo so 
the Stack thread can do the work
3) put the AppTimers in a separate Application TimerQueue

I think option 1 is not a good idea since most timers are created by the 
stack (by TransactionState). I'm leaning towards option 2 and will try 
implementing this one shortly.

Jason





More information about the resiprocate-devel mailing list