[asterisk-dev] [Code Review]: Remove some unnecessary locking from ast_hangup()

rmudgett reviewboard at asterisk.org
Fri Feb 3 15:29:32 CST 2012



> On Feb. 3, 2012, 10:28 a.m., rmudgett wrote:
> > Yes holding the channels container lock is not necessary.
> > 
> > However, your example about the audiohooks could still cause problems because the channel lock is held and many ao2_callbacks over the channels container also lock each channel in turn.
> > 
> > Would moving the audiohook and framehook destruction after the channel is unlinked be needed to completely avoid your example holding up the system?
> 
> Russell Bryant wrote:
>     That's a great point, Richard.  I'll make that change.
> 
> Alec Davis wrote:
>     The ao2_lock(channels) in ast_hangup() got added with the call pickup race.
>     https://reviewboard.asterisk.org/r/1400/
>     
>     Hopefully, it won't be re-broken,

Thanks Alec, it likely would break pickup again.

The pickup fix depends on the ZOMBIE flag being set.  ast_hangup() needs to either masquerade or get the ZOMBIE flag set before releasing the channel lock.

The ZOMBIE flag likely needs to be set earlier in the hangup.


- rmudgett


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1712/#review5395
-----------------------------------------------------------


On Feb. 3, 2012, 9:58 a.m., Russell Bryant wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1712/
> -----------------------------------------------------------
> 
> (Updated Feb. 3, 2012, 9:58 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch removes some unnecessary locking of the channels container in ast_hangup().  The reason this came up is that this lock can very quickly block the entire system.  If any of the channel cleanup code decides to block, it causes a problem for the whole system.  For example, when audiohooks get destroyed, if that blocks for a while waiting on the mixmonitor thread to exit because it's busy blocking on some I/O, it causes a problem for many other threads in the meantime.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/main/channel.c 353961 
> 
> Diff: https://reviewboard.asterisk.org/r/1712/diff
> 
> 
> Testing
> -------
> 
> Ran under load in a test environment, about 1/2 million calls
> 
> 
> Thanks,
> 
> Russell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120203/258010aa/attachment-0001.htm>


More information about the asterisk-dev mailing list