[pjsip] Question about stream.c

Benny Prijono bennylp at pjsip.org
Thu Feb 14 09:33:25 EST 2008


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,
>




More information about the pjsip mailing list