: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
<[EMAIL PROTECTED]>
