From owner-freebsd-current Mon Aug 7 9:47:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843290.broadbandoffice.net [64.47.83.26]) by hub.freebsd.org (Postfix) with ESMTP id 496F337B50B; Mon, 7 Aug 2000 09:47:48 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.9.3/8.9.3) id JAA36775; Mon, 7 Aug 2000 09:47:36 -0700 (PDT) (envelope-from dillon) Date: Mon, 7 Aug 2000 09:47:36 -0700 (PDT) From: Matt Dillon Message-Id: <200008071647.JAA36775@earth.backplane.com> To: Mike Smith Cc: Alfred Perlstein , Stephen McKay , freebsd-current@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Ugly, slow shutdown References: <200008070836.BAA02380@mass.osd.bsdi.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> * Stephen McKay [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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message