RE: [reSIProcate] dum-based client instability - Application Time r not thread safe
Oops - never mind - my app and other must protect calls to send / process
from different threads anyway - so it shouldn't really be a concern. Sorry.
-----Original Message-----
From: Scott Godin
Sent: Monday, November 01, 2004 9:43 AM
To: 'Jason Fischl'; david Butcher
Cc: Resiprocate
Subject: RE: [reSIProcate] dum-based client instability - Application Timer
not thread safe
If we go with option 3, maybe we will still need to put a lock around the
app timer queue. Since some app timers may be started from the stack thread
and/or the application thread. ie. InviteSession::send().
-----Original Message-----
From: Jason Fischl [mailto:jason@xxxxxxxxxxxxxx]
Sent: Saturday, October 30, 2004 6:59 AM
To: david Butcher
Cc: Resiprocate
Subject: 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
>>
>>
>>
>
>
>
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel