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 http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
