[pjsip] Question about stream.c

Michael Broughton Michael_Broughton at advanis.ca
Thu Feb 14 10:36:34 EST 2008


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.





More information about the pjsip mailing list