[asterisk-dev] [Code Review] app_directed_pickup Implement the ability to remove a channel group on bridged channel

[irroot]

> On 2011-05-27 09:09:52, David Vossel wrote:
> > /trunk/main/channel.c, lines 6498-6504
> > <https://reviewboard.asterisk.org/r/1118/diff/9/?file=16758#file16758line6498>
> >
> >     There is only one time in the entire code base where deadlock avoidance is absolutely necessary and that is when multiple channels are being locked at the same time.  This is because there is no locking order established for locking multiple channels.
> >     
> >     With everything else, there is a locking order established.  In this case the channels container must always be locked before an individual channel.  Deadlock avoidance is not necessary here.
> >     
> >     So, never use deadlock avoidance unless you have to grab two channel locks at the same time, otherwise it is not necessary.  I know the code has misuses of deadlock avoidance all over the place, ignore them.  They will go away in time.
> >     
> >     As a side note, if you ever find yourself in the position where you are designing a program and think using deadlock avoidance is a quick solution for a concurrency problem you run into, it is not.  Running into a deadlock almost certainly means your design is flawed.  I'd go as far as to say if you ever find yourself designing a system with multiple locks held at the same time, your design is flawed.  Seriously, anyone who reads this remember this, and say it to yourself every time you create a new mutex.

RB 1234 is addressing the cause of this problem and this "plaster" should not be put into the code however i have to deal with most annoyed users when there call center locks up ... i have to wear 2 hats one to make sure the user can use the system and one to improve the system putting a plaster on the problem might not be right but allows time to fix the underlying problem ill not include this sort of plaster but to be able to discuss / fix the problem.


- irroot


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


On 2011-05-26 13:32:29, irroot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1118/
> -----------------------------------------------------------
> 
> (Updated 2011-05-26 13:32:29)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> as a companion to 0018825 to aid with the move from call-limits to channel group variables. the problem with pickup and queue is that they manage channels outside the dialplan and need "helpers" to deal with channel groups.
> 
> in the case of pickup when a call is placed to a extension with say a "<EXTEN>@called" channel group when it is picked up this needs to be cleared to allow further calls when call waiting is disabled.
> 
> exten => s,n,GotoIf($[$[${ GROUP_COUNT(${ARG1}@called)} >= 1] | $[${GROUP_COUNT(${ARG1}@caller)} >= 1] | $[${GROUP_COUNT(${ARG1}@pickup)} >= 1] | $[${GROUP_COUNT(${ARG1}@qagent)} >= 1]]?s-BUSY,1)
> 
> where
> caller is set when a call is placed.
> called is set when a call is received
> pickup is set when before calling pickup in the dialplan
> qagent is set with patch to queue
> 
> Hope this is found to be useful and finds a home in trunk. 
> 
> not sure what time to put in the "wait for bridge" perhaps there is a better method ?? 
> 
> 
> This addresses bug 18830.
>     https://issues.asterisk.org/view.php?id=18830
> 
> 
> Diffs
> -----
> 
>   /trunk/main/channel.c 320937 
> 
> Diff: https://reviewboard.asterisk.org/r/1118/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> irroot
> 
>

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