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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
