:> * Stephen McKay <[EMAIL PROTECTED]> [000805 08:49] wrote:
:> >
:> > Patch 2 is smaller and possibly controversial. Normally bufdaemon and
:> > syncer are sleeping when they are told to suspend. This delays shutdown
:> > by a few boring seconds. With this patch, it is zippier. I expect people
:> > to complain about this shortcut, but every sleeping process should expect
:> > to be woken for no reason at all. Basic kernel premise.
:>
:> You better bet it's controversial, this isn't "Basic kernel premise"
:
:Actually, that depends. It is definitely poor programming practice to
:not check the condition for which you slept on wakeup.
:
:> *boom* *crash* *ow* :)
:
:Doctor: So don't do that.
I gotta agree. This is very bad programming practice. There are many,
many places in the kernel where tsleep() is called with a 0 delay and
assumed not to return until something meaningful happens. For example,
for handling NFS retries, some of the locking code (I think), and I
could probably find many others.
In general 'quick hacks' only cause immense pain later on... sometimes
years later on. It is NOT WORTH IT.
In the case of buf_daemon, waking up the process is a definite no-no.
You can wakeup &lbolt, but you can't just go wakeup the process
willy-nilly -- it could be sitting anywhere.
What I would suggest is to add another argument to the shutdown
event-handler registration, an optional wakeup address. If NULL,
no wakeup is performed. Otherwise a wakeup on the specified address
is performed. You can then pass &lbolt to it when the syncer &
buf_daemon processes register. That is a simple, safe solution.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message