Date: Sat, 29 Apr 2000 15:37:16 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Justin T. Gibbs" <gibbs@freebsd.org> Cc: Archie Cobbs <archie@whistle.com>, freebsd-arch@freebsd.org Subject: Re: timeout(9) question Message-ID: <Pine.BSF.4.21.0004291514400.4400-100000@alphplex.bde.org> In-Reply-To: <200004281903.NAA03592@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004291514400.4400-100000>