From owner-freebsd-arch Mon Nov 1 12: 3: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 53F3A14A2F for ; Mon, 1 Nov 1999 12:02:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA07079 for ; Mon, 1 Nov 1999 21:02:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA74891 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:02:41 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6663E14BE5; Mon, 1 Nov 1999 12:02:10 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA17348; Mon, 1 Nov 1999 13:02:07 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA18597; Mon, 1 Nov 1999 13:02:02 -0700 Date: Mon, 1 Nov 1999 13:02:02 -0700 Message-Id: <199911012002.NAA18597@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Eischen Cc: Nate Williams , "Justin T. Gibbs" , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199911011907.MAA18241@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You and I are on the same track here. This is the kind of functionality > > I would like to see, and I proposed something like that in an email to > > the group. The only downsides to execption handling is that it often > > makes your code a bit harder to read if you get really anal about > > exception handling. :) > > > > > There are several situations where you really do want to abort threads > > > in a kernel context (even those that are not explicitly sleeping) and > > > whatever solution we devise should allow for it to occur. > > > > Agreed, but it needs to be a 'signal' or an 'exception' to the thread, > > so the thread itself can unwind, rather than having it abort. > > > > That way the thread itself can clean up as it sees fit... > > What about being able to push and pop cleanup handlers in the > kernel? It's not quite as elegant as exception handlers, but > would it accomplish what you want? I think the complexity would be much greater, but maybe I don't understand fully what you are saying. Can you give a simple code example? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message