Benny Prijono wrote: > 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! > > Correct, but I was thinking that the timeout in acquire_call would allow for a graceful failure (soft deadlock). I suppose it isn't a big deal if a DTMF event is dropped while you are trying to shutdown the stream. > So maybe having call lock in on_dtmf() callback is not a good idea after all). > > For my application, I think it is necessary because I need to manipulate the call from the DTMF callback. I don't think handling the DTMF events asynchronously will be responsive enough, and may cause other timing issues with my application. > 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 > -- Michael Broughton, Advanis Unintended Recipient & Unauthorized Use of E-Mail: This message and attachments may contain confidential or privileged information that is intended only for the named recipient of this e-mail. Any unauthorized use or distribution is not permitted. If you have received this e-mail in error, deleting the e-mail and notifying the sender would be appreciated. Thank you.
