--- "Justin T. Gibbs" <[EMAIL PROTECTED]> wrote: > >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? > > -- > Justin
I have a patch which is very like what you said here. I set a flag between "commit" and "return", and blocking callout_stop() caller if it is not in softclock() context, the patch still has some problems, for example lock oder reversal which is pointed out by jhb. but Archie Cobbs and others are talking about another resolution, I will set back. David Xu __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
