From owner-freebsd-arch Fri Apr 28 22:37:38 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 62DF737B718 for ; Fri, 28 Apr 2000 22:37:35 -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 HAA26685 for ; Sat, 29 Apr 2000 07:37:33 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA08956 for freebsd-arch@freebsd.org; Sat, 29 Apr 2000 07:37:32 +0200 (CEST) Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 5071A37B7BA for ; Fri, 28 Apr 2000 22:37:24 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 14572 invoked from network); 29 Apr 2000 05:37:21 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 29 Apr 2000 05:37:21 -0000 Date: Sat, 29 Apr 2000 15:37:16 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: "Justin T. Gibbs" Cc: Archie Cobbs , freebsd-arch@freebsd.org Subject: Re: timeout(9) question In-Reply-To: <200004281903.NAA03592@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Apr 2000, Justin T. Gibbs wrote: > >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. Especially when the routine that called timeout() was called at splbar(). The combined ipl is (splbar(); splfoo();). timeout() would have no way of disentangling the spls to get back to the one that you think you want (splfoo()) unless the timeout() interface is bloated to pass a pointer to the desired spl function. Anyway, no races can be fixed by doing the spl in the timeout dispatcher instead of in the individual handlers, since the dispatcher needs to reduce the ipl to splsoftclock() for handlers that want to run at that ipl. > 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. No, only timeouts are serialized. Other software interrupts can interrupt timeout handlers unless the other interrupts are blocked using splfoo() in the handlers. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message