[asterisk-dev] Fwd: [svn-commits] jrose: trunk r403588 - in /trunk: ./ channels/chan_pjsip.c

[Joshua Colp]

Matthew Jordan wrote:
> I'm not sure this should have been committed.
>
> I hadn't seen that this had already been put up for review, otherwise I
> would have commented on the review - however, I did note the following
> on the issue:
>
> You can't delay a masquerade. Failing to complete the fix up here will
> result in a masqueraded (zombie) channel with an active session.
> Anything using that session will be pointing to the Zombie channel, and
> - assuming they don't blow up in some spectacular fashion - have a high
> likelihood of simply failing.

I think we need to actually explore the consequences of this some 
instead of sticking to theoretical. I suspect that if there were a task 
ahead of the fixup to hang stuff up it would probably keep the zombie in 
limbo, so that's one thing.

> Even if we assume that the task can be put at the front of the
> taskprocessor queue, any operation currently in flight will be operating
> on an invalid channel.
>
> I only see two possibilities here:
>
>  1. Fix the locking inversion between the task processor and the entity
>     pushing the synchronous task. That is, you can't hold a channel lock
>     when pushing a synchronous task.

Going down this road

>  2. Go with a modified version of the patch, but assume that the session
>     object has to be protected as well.

I think pending some other miracle or delaying the fixup not being as 
bad as we all think it is... that'll be the solution.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org