[asterisk-dev] [Code Review] Improve timing interface to remember which provider provided a timer

Kevin Fleming kpfleming at digium.com
Fri Mar 27 06:41:14 CDT 2009



> On 2009-03-26 20:39:03, Eliel Sardañons wrote:
> > /trunk/channels/chan_iax2.c, line 260
> > <http://reviewboard.digium.com/r/211/diff/1/?file=3849#file3849line260>
> >
> >     I think this should be 'static'

That is correct; I'll fix it during the commit.


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/211/#review632
-----------------------------------------------------------


On 2009-03-26 18:46:08, Kevin Fleming wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/211/
> -----------------------------------------------------------
> 
> (Updated 2009-03-26 18:46:08)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The ability to load/unload timing interfaces is nice, but it means that when a timer is allocated, it may come from provider A, but later provider B becomes the 'preferred' provider. If this happens, all timer API calls on the timer that was provided by provider A will actually be handed to provider B, which will say WTF and return an error.
> 
> This patch changes the timer API to include a pointer to the provider of the timer handle so that future operations on the timer will be forwarded to the proper provider.
> 
> 
> This addresses bug 14697.
>     http://bugs.digium.com/view.php?id=14697
> 
> 
> Diffs
> -----
> 
>   /trunk/bridges/bridge_softmix.c 184495 
>   /trunk/channels/chan_iax2.c 184495 
>   /trunk/include/asterisk/channel.h 184495 
>   /trunk/include/asterisk/timing.h 184495 
>   /trunk/main/channel.c 184495 
>   /trunk/main/timing.c 184495 
> 
> Diff: http://reviewboard.digium.com/r/211/diff
> 
> 
> Testing
> -------
> 
> Compile testing only.
> 
> 
> Thanks,
> 
> Kevin
> 
>




More information about the asterisk-dev mailing list