From owner-freebsd-arch Fri Apr 28 12: 8:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A58AE37B91C for ; Fri, 28 Apr 2000 12:08:34 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA20831 for ; Fri, 28 Apr 2000 21:08:28 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA04250 for freebsd-arch@freebsd.org; Fri, 28 Apr 2000 21:08:28 +0200 (CEST) Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id D58D337B86F for ; Fri, 28 Apr 2000 12:03:02 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id NAA03592; Fri, 28 Apr 2000 13:03:00 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200004281903.NAA03592@caspian.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Archie Cobbs Cc: freebsd-arch@freebsd.org Subject: Re: timeout(9) question In-Reply-To: Your message of "Fri, 28 Apr 2000 10:14:59 PDT." <200004281714.KAA73019@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Apr 2000 13:03:00 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Question: > >Why doesn't the timeout(9) routine call the handler function at >the same spl level that the timeout was registered? Because it is not obvious that you would get the desired behavior. Just because you happen to be at splfoo() at the time that you perform a call to timeout() does not mean that you want or even need your handler to run at that level. >The way it works now, it seems like there's an unavoidable race >condition. It is avoidable, if necessary, by adding and maintaining additional state. Software interrupts are serialized. This implies that no other software interrupt (including the network software interrupt that is blocked by splnet()) can pre-empt you during the execution of your handler. Naturally, this does not prevent hardware interrupts from getting in there. >Another thing that bugs me is there's not an easy way to check if >a timeout is already registered, eg: > > extern int timeout_registered(struct callout handle); Use the callout interface instead of timeout. timeout(9) should be deprecated anyway. Perhaps Garret will write up a new man page for the callout interface since he added it, but until then, take a look at sys/callout.h. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message