[asterisk-dev] chan->_softhangup

[Damien Wedhorn]

Tilghman Lesher wrote:
> It's basically used as a general purpose inter-thread signal.  Whether you
> call it softhangup or not, I don't think that the semantics are terribly
> difficult, although the fact that all the possible causes are gathered
> together in a single bitwise field is nice.
>   
That's the fundamental problem. It is both a general purpose bitfield
and a specific purpose variable. If any bit is set and there is an
active bridge, the bridge will be torn down unless the bits are all
reset before the lock is released, irrespective of what the intent of
the specific bit is. My initial mail probably wasn't that clear.
> I'd like to see your alternative proposal before I'd comment on whether the
> cure is worse than the disease.  Just the general purpose overview is fine,
> along with how each of the various bits currently used in softhangup would
> be better served (or not, as the case may be) by your proposal.
>   
Unfortunately I think it's going to be a significant task with lots of
swings and roundabouts. I want to get some feedback before I wander too
far down this road. I don't think a complete change can occur in a
single patch as it would be too extensive and will probably induce bugs
because there is too much interplay between all of the different bits of
code, hence my suggestion of an iterative approach, that is, fix up a
little bit at a time. Also, given the extensive usage of softhangup, it
is used in many areas that I am completely unfamiliar with the code.

For info, softhangup is tested or set in about 300 different places in
asterisk. Understanding of it's specific purpose would need to be
understood for each of those cases before modifying, although about 100
of those are through the ast_check_hangup function which should be
fairly easy to replace with a check against the last frame on the queue.

Damien Wedhorn