From owner-freebsd-current Fri Jun 25 10:17:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8B4CF14D09; Fri, 25 Jun 1999 10:17:24 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA27119; Fri, 25 Jun 1999 10:17:32 -0700 Date: Fri, 25 Jun 1999 10:15:55 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin T. Gibbs" Cc: current@FreeBSD.ORG, tech-kern@FreeBSD.ORG, tech@openbsd.org Subject: Re: Changing the semantics of splsoftclock() In-Reply-To: <199906251640.KAA01742@caspian.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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