From owner-freebsd-arch Sun Oct 31 20:13: 4 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 0133B15291 for ; Sun, 31 Oct 1999 20:12:50 -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 FAA02598 for ; Mon, 1 Nov 1999 05:12:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA70403 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 05:12:49 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id E595C14BD3 for ; Sun, 31 Oct 1999 20:12:36 -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 VAA09451; Sun, 31 Oct 1999 21:12:34 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA14975; Sun, 31 Oct 1999 21:12:32 -0700 Date: Sun, 31 Oct 1999 21:12:32 -0700 Message-Id: <199911010412.VAA14975@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: julian@whistle.com, nate@mt.sri.com, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199911010347.WAA20149@pcnet1.pcnet.com> References: <199911010347.WAA20149@pcnet1.pcnet.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 > > > 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. :) > > No, I want to be able to have multiple threads in a single process > be in kernel space. Only one can be running, but others can be > blocked. Agreed. My point is that if we allow multiple threads in a single process in the kernel space, it's alot worse than the present tsleep issues.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message