Review Board 1.7.16

Add common implementation for a scheduler context with a dedicated thread

Review Request #129 - Created Jan. 24, 2009 and submitted

Russell Bryant
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.
It compiles.  Basic chan_iax2 usage appears unaffected.
Review request changed
Updated (Jan. 26, 2009, 9:21 a.m.)
Added updated diff inspired by the comments from Mark.

I haven't added a sched_replace API call, yet, as I'm not sure whether it needs to be atomic or not.  (I don't think it does ...)

I started to make the changes to use poke() when I realized that the lock needed to be held before calling add(), so poke() couldn't be used in the end. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to