Date: Fri, 25 Jun 1999 10:15:55 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> Cc: current@FreeBSD.ORG, tech-kern@FreeBSD.ORG, tech@openbsd.org Subject: Re: Changing the semantics of splsoftclock() Message-ID: <Pine.BSF.4.05.9906251015090.38018-100000@semuta.feral.com> In-Reply-To: <199906251640.KAA01742@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Why have splr semantics? That is, it raises to splsoftclock if current priority is lower, else doesn't fiddle with it. On Fri, 25 Jun 1999, Justin T. Gibbs wrote: > I've come across several instances where I need to fiddle with state that > is also touched by a timeout handler. From a naming standpoint, > splsoftclock() sounds like the correct spl routine to use for protecting > these activities. Unfortunately this only holds true if splsoftclock() > is used in a process context where the fact that it may actually lower > the ipl to softclock is not an issue. As it currently stands, in most > cases you can rely on the fact that any spl level will also block callouts, > but this seems risky. What I'd like to see happen is for either the > semantics of splsoftclock() to change, or to have a new spl introduced > (splcallout()??). The hope is to provide a consistent interface across > all *BSDs which is why I've addressed this to all of the *BSD projects. > I look forward to you input on this proposal. > > -- > Justin > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.05.9906251015090.38018-100000>