I'll work out a patch to see if my idea works.

David Xu

--- John Baldwin <[EMAIL PROTECTED]> wrote:
> On 08-Jul-2002 David Xu wrote:
> > I want to set an flag bit CALLOUT_PROCESSING in callout.c_flags,
> > before softclock() releases callout_lock and start requesting
> > callout.c_func(), so callout_stop can find that callout is processing
> > by softclock and wait, after softclock processed the callout, it
> > resets the flag and wakeup callout_stop thread, of course, if
> > callout_stop is being called in softclock() thread, it should avoid
> > waiting, it is easy to detect.
> This doesn't work.  The callout function can do a callout_reset() on
> itself to reschedule itself.  Well, if all the various callout functions
> check for the processing flag it might work.  Then you have to figure out
> how to properly wait.  You can't use a cv as they don't work with spin
> mutexes.  Hmmm, this is one of the times I wish we could wait on a cv with
> a spin mutex.  You could do something evil where you had a cv and a mutex,
> unlocked callout lock, locked mutex, locked callout lock, rechecked
> condition, then blocked if needed.  Similar evilness required when doing
> a wakeup as well.  We can cheat in the endtsleep() case because we know
> what thread to wakeup as well.  We don't easily have that in the general
> case unless we bloat struct callout a bit.
> -- 
> John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to