I'll work out a patch to see if my idea works.
--- 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