[asterisk-dev] [Code Review] Add common implementation for a scheduler context with a dedicated thread

[Mark Michelson]

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



/trunk/channels/chan_iax2.c
<http://reviewboard.digium.com/r/129/#comment743>

    Why is it that scheduler entry replacement is not an atomic operation? At the least, I would expect a lock to be held around the calls to ast_sched_thread_del and ast_sched_thread_add so that nothing could happen between the deletion and addition. I ask also because the pre-existing AST_SCHED_REPLACE macro does not hold a lock around the removal and re-addition of scheduler entries.
    
    Even though replacement can be accomplished as you have done here with separate calls to delete and add a scheduler entry, why not add a simple public API function for replacing scheduler entries (e.g. ast_sched_thread_replace)?



/trunk/include/asterisk/sched.h
<http://reviewboard.digium.com/r/129/#comment739>

    Why did you change this?



/trunk/main/sched.c
<http://reviewboard.digium.com/r/129/#comment741>

    You can replace the contents of this block with ast_sched_thread_poke(st)



/trunk/main/sched.c
<http://reviewboard.digium.com/r/129/#comment742>

    You can replace the contents of this block with ast_sched_thread_poke(st)


- Mark


On 2009-01-24 15:03:41, Russell Bryant wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/129/
> -----------------------------------------------------------
> 
> (Updated 2009-01-24 15:03:41)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> There are a number of modules that create a scheduler context.  Some use a dedicated thread, while others process the scheduler context within the context of a thread that handles other things as well.  I have noticed a number of bugs in both types of implementations related to race conditions between checking how much time until the next scheduled entry and sleeping for an appropriate amount of time.
> 
> To address the problems found in the implementations that use a dedicated thread, I have written this patch.  This patch adds a common implementation of a scheduler context that uses a dedicated thread for processing.
> 
> chan_iax2 has been updated to use this new API for its dedicated scheduler thread instead of the one that was written into chan_iax2 directly.  The previous implementation has some race conditions that can lead to the scheduler thread sleeping longer than it is supposed to, leading to scheduled actions not running when they are supposed to.  Bugs caused by this type of thing are often very subtle and difficult to track down.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_iax2.c 170834 
>   /trunk/include/asterisk/sched.h 170834 
>   /trunk/main/sched.c 170834 
> 
> Diff: http://reviewboard.digium.com/r/129/diff
> 
> 
> Testing
> -------
> 
> It compiles.  Basic chan_iax2 usage appears unaffected.
> 
> 
> Thanks,
> 
> Russell
> 
>