[asterisk-dev] [Code Review] Tweak chan_local device state reporting

Mark Michelson reviewboard at asterisk.org
Wed Sep 19 13:29:54 CDT 2012


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



/branches/1.8/channels/chan_local.c
<https://reviewboard.asterisk.org/r/2116/#comment13694>

    I suggest locking lp since you are now checking a piece of data that is not constant on the local_pvt


- Mark


On Sept. 18, 2012, 10:54 a.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2116/
> -----------------------------------------------------------
> 
> (Updated Sept. 18, 2012, 10:54 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Improving the device state handling of app_queue so it only calls a member if the member is not in use or their state is unknown caused a regression when using Local channels. Presently Local channels report their state as in use once requested and NOT when called. This seems to be incorrect as requesting a channel does not fundamentally cause it to be in use. It is only once called that is actually in use. This patch changes Local device state reporting to only report in use once called. Instead of directly making this change I am asking for feedback on here to get the opinions of others on this change.
> 
> 
> This addresses bug ASTERISK-20390.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20390
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_local.c 373118 
> 
> Diff: https://reviewboard.asterisk.org/r/2116/diff
> 
> 
> Testing
> -------
> 
> Tested change against original issue to confirm issue has been resolved, and it is.
> Tested other call scenarios using Local channels to make sure they are still reported as in use, and they are.
> 
> 
> Thanks,
> 
> Joshua
> 
>

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


More information about the asterisk-dev mailing list