Re: cvs commit: src/sys/dev/sound/pci/hda hdac.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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()?
:
:cheers
:  simon

    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
    kern_timeout.c.

    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>