>I believe I had this conversation with Justin Gibbs earlier; he told
>me that the callout consumers (network, cam) had to be aware of the
>race and handle this if it matters. I don't particularly like complicating
>the callout handlers as illustrated above, though, so if a better scheme
>is possible, that would be nice.
If callout_stop() is always called from a context that can block and
we desire the semantics that upon return from callout_stop(), you are
not in the callout handler, it seems that this should be quite easy to
achieve. Just track the state of the callout from "commit" and "return",
via some flags locked by a global mutex. If a callout_stop is called
between "commit" and "return" (just look at a global indicating the
currently running callout protected by this mutex), put the thread on a
list to be woken by the thread issuing the callout. To handle the case of
a reschedule performed by the callout itself, the woken up caller to
callout_stop() will have to loop through the test again. In all cases,
the global mutex is only held for very short operations as a leaf mutex.
>tsleep() is only called from process context
With interrupt threads, isn't "process context" a bit of a misnomer?
Would it be acceptable for the "interrupt threads" that perform callout_stops
to block waiting for them to take effect?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message