Date: Fri, 28 Apr 2000 13:03:00 -0600 From: "Justin T. Gibbs" <gibbs@freebsd.org> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: timeout(9) question Message-ID: <200004281903.NAA03592@caspian.plutotech.com> In-Reply-To: Your message of "Fri, 28 Apr 2000 10:14:59 PDT." <200004281714.KAA73019@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004281903.NAA03592>