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

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


Oops.

Might want to consider choice 3 and (eventually) use a timer wheel since the 
timers associated with the stack are bounded.

david

> 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
> 
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>