[asterisk-dev] chan->_softhangup

[Tilghman Lesher]

On Saturday 20 February 2010 16:42:59 Damien Wedhorn wrote:
> I am (was?) looking at changing the chan->_softhangup to be atomic so as
> part of the readq locking in channel.c (reason being is that it remove a
> lot - most? - of the chan locking requirements in chan_*).
>
> Anyway, in order to work out the best way of atomicising changes to
> _softhangup, I came to the conclusion that the need for having
> chan->_softhangup is probably dubious at best. That's not saying that it
> is not used, it actually shows up all through the code. But, it doesn't
> seem to do a lot and the few things that it actually does would probably
> be better dealt with in a different manner.

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.

> Some code explicitly sets _softhangup with looking at what is already
> there effectively overwriting anything that may have been previously set.

I think those are probably bugs.  Anything that sets softhangup should
manipulate, at most, one bit.

> Rather than trying to make the softhangup stuff atomic, I suggest that
> we look at removing softhangup completely. Given the various and
> different usage of softhangup, various things need to be undertaken.
> Namely, where a test is purely to see whether a hangup is imminent, we
> can test whether the last frame of the queue is a hangup. And where the
> usage is to obtain feedback from some other function, the function is
> either rewritten or feedback obtained another way, either through res or
> an additional specific chanvar.

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.

-- 
Tilghman Lesher
Digium, Inc. | Senior Software Developer
twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
Check us out at: www.digium.com & www.asterisk.org