[asterisk-dev] [Code Review] chan_sip, kill deadlock avoidance in do_monitor.

[David Vossel]

> On 2011-04-14 11:39:48, rmudgett wrote:
> > /branches/1.8/channels/chan_sip.c, line 7460
> > <https://reviewboard.asterisk.org/r/1182/diff/1/?file=16163#file16163line7460>
> >
> >     How about eliminating the do/while loop and done flag with:
> >     
> >     for (;;) {
> >       ...
> >       if (pvt->owner == chan) {
> >         break;
> >       }
> >       ast_channel_unlock(chan);
> >       ast_channel_unref(chan);
> >       ast_pvt_unlock(pvt);
> >     }

yeah, I can do that.


- David


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


On 2011-04-14 11:16:21, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1182/
> -----------------------------------------------------------
> 
> (Updated 2011-04-14 11:16:21)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Deadlock avoidance between the sip pvt and the pvt->owner is very difficult.  Now that channel's are ao2 objects, this complication is no longer necessary.  It turns out the pvt's msg queue only exists because of deadlock avoidance (when deadlock avoidance fails msgs were added to a queue to be processed later), so this goes away as well.
> 
> The technique used in the new sip_lock_pvt_full() function should be used as a template for replacing all locations where deadlock avoidance occurs between a channel tech_pvt and the pvt's owner.  My hope is that this will begin a reversal of the invalid channel driver locking architecture we have been using for so long. 
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 313741 
> 
> Diff: https://reviewboard.asterisk.org/r/1182/diff
> 
> 
> Testing
> -------
> 
> I have tested this briefly.  It will be proven under load before being introduced into any branch.
> 
> 
> Thanks,
> 
> David
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110414/c256f25e/attachment.htm>