From owner-freebsd-current Fri Jun 25 9:53:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 80F6415746 for ; Fri, 25 Jun 1999 09:53:31 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id KAA01796; Fri, 25 Jun 1999 10:53:25 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199906251653.KAA01796@caspian.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: current@FreeBSD.org, tech-kern@NetBSD.org, tech@openbsd.org Subject: Changing the semantics of splsoftclock() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jun 1999 10:53:25 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Sorry for the duplicate message for some of you. I botched the headers on the original mail. ] 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