From owner-freebsd-arch Sun Oct 31 19: 3:18 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 7540814E8B for ; Sun, 31 Oct 1999 19:03:14 -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 EAA01679 for ; Mon, 1 Nov 1999 04:03:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA69677 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 04:03:14 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3D99D1509F for ; Sun, 31 Oct 1999 19:02:43 -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 UAA08649; Sun, 31 Oct 1999 20:02:37 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id UAA14279; Sun, 31 Oct 1999 20:02:36 -0700 Date: Sun, 31 Oct 1999 20:02:36 -0700 Message-Id: <199911010302.UAA14279@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Nate Williams , Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: References: <199911010219.TAA13936@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 > > > > 11.) Ability for the threads library to cancel/terminate a thread > > > > blocked in the kernel. > > > > > > oooooh > > > > Oooh is right. This has the potential to deadlock the kernel if the > > thread owns some sort of 'thread' resources. Justin and I were having a > > discussion about this very thing earlier today, and I don't think I was > > able to express myself well, so here it goes again. > > > > Basically, what happens if a particular thread owns a resource that > > others are blocking on, and it's woken up 'prematurely'? If the thread > > is aborted out of the kernel, the other threads (which might exist in > > the kernel) may not be woken up (ever), thus causing zombie threads. > > I think what is being asked for is the thread version of the > signal catching capabilities of the present tsleep(). > The situation is no worse than it is at present. Sort of, except that for every process you can only have one thread in kernel space, so the only deadlocks that can occur happen in userland, since the kernel has no primitives for doing 'synchronization' and notification. (Unless you consider the SysV stuff, but as we've seen, people tend to screw up using that as well. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message