From owner-freebsd-arch Sun Oct 31 18:45:34 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 2558F14ECA for ; Sun, 31 Oct 1999 18:45:31 -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 DAA01532 for ; Mon, 1 Nov 1999 03:45:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69564 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:45:30 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id D63D614ECA for ; Sun, 31 Oct 1999 18:45:25 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA30671; Sun, 31 Oct 1999 18:45:21 -0800 (PST) Date: Sun, 31 Oct 1999 18:45:18 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: Daniel Eischen , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010219.TAA13936@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 Oct 1999, Nate Williams wrote: > > > 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. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message