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
>