Benny Prijono wrote: > I think you're probably right, the callback thread would eventually > timeout when it tries to call acquire_call(). The scenario would be > like this: > > transport thread: > 1. on_dtmf callback is called (with ioqueue's key mutex held) > 2. tries to lock call with acquire_call() > > Application thread: > 3. acquire_call() returns successfully > 4. close transport, which eventually try to get ioqueue's key mutex > > This is a deadlock scenario. But with soft deadlock protection, step > no 2 above would time out eventually, and everything will run again. > > But soft deadlocking is very expensive in term of processing, as > everything that tries to lock PJSUA-LIB will be blocked while > PJSUA-LIB tries to acquire (and finally gives up) the locks. This > would block the application for at least 1 second for the best case, I > think. > > What if acquire_call monitored a flag that indicates when the transport trying to shutdown? My own solution to ticket 460 sort-of worked that way. I'm not sure if there is a clean way to implement this... > > What about if you only post the destroy request to other thread, and > handle everything else in the callback? Anyway the deadlock situation > should only occur when we're trying to destroy the transport, so for > everything else, it should be safe to process the call (and call > acquire_call()) in the callback. > Sorry, I think I am leaving out too many details. I already defer any call drops to my main loop. I have far too much cleanup work to do after a call to do it in a callback. -- 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.
