From owner-freebsd-current Wed Sep 24 16:03:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA05304 for current-outgoing; Wed, 24 Sep 1997 16:03:22 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA05281 for ; Wed, 24 Sep 1997 16:03:13 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id QAA22758; Wed, 24 Sep 1997 16:03:01 -0700 (MST) From: Terry Lambert Message-Id: <199709242303.QAA22758@usr03.primenet.com> Subject: Re: new timeout routines To: julian@whistle.com (Julian Elischer) Date: Wed, 24 Sep 1997 23:02:59 +0000 (GMT) Cc: gibbs@plutotech.com, nate@mt.sri.com, tlambert@primenet.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <3429630C.167EB0E7@whistle.com> from "Julian Elischer" at Sep 24, 97 11:59:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > there is an assumption in a lot of code that untimeout is idempotent > (did I get that right?). It can be called whenever you are recovering > from unknown situations with the sure knowledge that the appropriate > timeout will be removed. This is kind of a bad assumption; it assumes no kernel preemption. It also probably means that the timeout is being scheduled way earlier than it should be in the code (before parameter checks, etc.). > 1/ there is no way to do this without lots of work now. > 2/ old code will break. The new code is actually expecting to be called reflexively. This is not a bad thing. All the lock code works this way (for example). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.