On 2/15/08, Michael Broughton <Michael_Broughton at advanis.ca> wrote: > > Wouldn't this still be prone to some race condition? The on_dtmf() > > callback might get the variable before the destroy thread sets it. > > Well, it is looping while trying to acquire a lock... so if it has a > reference to the flag, it can just check it on each iteration before the > timeout is reached. > Ah I see, so the check is in acquire_call(). Yeah that could work actually. > > The only clean solution that I could think of is to post the destroy > > request to main thread. But you've said that you didn't like this one, > > so... > > Destroy requests only happen from my main thread and possibly a SIP > worker thread. Sorry if I was unclear about this. > No, it's me who's talking rubbish there. The immediate destroy on the dtmf callback is not the problem being discussed in the first place. > The problem is that in rare situations I receive DTMF events and try to > drop a call at the same time. > Btw this problem only occurs if you destroy the media transport when dropping the call. Destroying the stream should be safe to do. So are you sure you're also destroying the transport? Because currently there's no way to do this in PJSUA-LIB. cheers, -benny > > -- > Michael Broughton, Advanis
