cvs commit: src/sys/dev/sound/pci/hda hdac.c
dillon at apollo.backplane.com
Tue Jun 26 10:54:16 PDT 2007
:When would this happen? Do you think of this:
:1. callout starts running, clears CALLOUT_PENDING
: 2. other cpu runs callout_stop(), tests for CALLOUT_PENDING
: 3. callout_stop() is happy, returns
:4. callout runs callout_reset, enables callouts again
:so my question here is: why don't we check for CALLOUT_ACTIVE in the first place? If the callout is not ACTIVE, there is no way that it can fire.
:Your change looks good, but what's this CALLOUT_ACTIVE business anyways? I'd use it to signal "callout running right now". Or is it just something like !callout_stopped()?
CALLOUT_PENDING is a badly named flag is what it is. It means the
callout is on the timeout tailq. This is used internally by
CALLOUT_ACTIVE is used by users of the callout API. This flag is
set by callout_reset() and cleared by callout_stop() but otherwise
not messed with by the callout code. Execution and dequeueing of a
callout does not clear the flag.
Users can clear the flag without dequeueing the callout by calling
callout_deactivate(). This does not prevent the callout from running,
but those same users can also test the flag with callout_active().
This is basically done as a performance enhancer to deactivate a
callout without actually dequeueing it, and then test whether it has
been deactivated if/when the callout callback is made. This enhances
performance in those cases where a callout might be about to be
requeued anyway. TCP uses this a lot.
<dillon at backplane.com>
More information about the Commits