Re: [reSIProcate] dum-based client instability - Application Timer not thread safe
I've already implemented most of option 3 - although not the timer
wheel. Will check it in tomorrow.
Jason
david Butcher wrote:
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