From owner-freebsd-arch Mon Nov 1 13: 0:20 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 9481F14F02 for ; Mon, 1 Nov 1999 13:00:02 -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 WAA07904 for ; Mon, 1 Nov 1999 22:00:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA75429 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 21:59:59 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 63B6914F02; Mon, 1 Nov 1999 12:59:27 -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 NAA18474; Mon, 1 Nov 1999 13:59:23 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA19090; Mon, 1 Nov 1999 13:59:22 -0700 Date: Mon, 1 Nov 1999 13:59:22 -0700 Message-Id: <199911012059.NAA19090@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: <199911012002.NAA18597@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 > > > 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? > > see man pthread_cleanup_push(3). If a kernel thread were abnormally > terminated it would run down its list of cleanup handlers to free > held resources. That's much more complicated that doing exception handling, since it's *very* obvious what happened when dealing with exceptions. Otherwise, you have to make some guesses as to which resource caused problems, and such. It might even be able to recover in some cases, depending on where the error occurred. This is how C++/Java do things, and it's very intuitive... (Modula-3 might also do this, but I'm not familiar enough with them to say with authority...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message