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

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