On 2/13/08, Michael Broughton <Michael_Broughton at advanis.ca> wrote: > Looks better than my solutions. > > As far as the DTMF callback is concerned, I think that the timeout in > the acquire_call function should be enough to cover our butts. Agreed? > Erm, we have three cases to handle, lets exercise them here. First is processing DTMF callback while other thread is trying to destroy the stream/call. This scenario is the same as our original stream problem, so it should have been fixed by the latest patch. We wouldn't even get into the soft deadlock state as on_dtmf() callback, so we should be safe. (this still assumes current situation where on_dtmf() callback doesn't hold any call mutexes. Once we change on_dtmf() to acquire call mutex, then yes, this would be covered by acquire_call(), i.e. one of the thread will wait until the other is done Although, hmmm.. thinking about it again, if we implement call locking in on_dtmf() callback, actually we will get into deadlock, as media transport mutex is not included in the standard lock order! So maybe having call lock in on_dtmf() callback is not a good idea after all). The second case is destroying the call in the DTMF callback itself, but leaving the UDP transport alive. This scenario also should be safe. The third case is destroying the call *and* the UDP transport in the DTMF callback. The difference between this and scenario 2 is when the UDP transport is destroyed, so is the pool associated with it, so all memory belonging to the UDP transport will be invalid after UDP transport is destroyed. For the third scenario, it was not safe to do that, but this should have been fixed by http://trac.pjsip.org/repos/ticket/469#comment:2, I think. So all cases should be covered for now. cheers, -benny > Thanks Benny, >
