From owner-freebsd-arch Sun Oct 31 18:26:53 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 D454F153A6 for ; Sun, 31 Oct 1999 18:26:34 -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 DAA01282 for ; Mon, 1 Nov 1999 03:26:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69372 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:26:33 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 73BA614D57 for ; Sun, 31 Oct 1999 18:25:33 -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 TAA08315; Sun, 31 Oct 1999 19:25:33 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA14010; Sun, 31 Oct 1999 19:25:32 -0700 Date: Sun, 31 Oct 1999 19:25:32 -0700 Message-Id: <199911010225.TAA14010@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: freebsd-arch@freebsd.org Subject: Re: Threads goals version II In-Reply-To: References: 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 > ---Possible system design goals of system threads support -- > --- Note just becasue something is in this list doesn't mean that > it will be done, just that it's going o be carried forward to > further discussion. > -------------------------------------------------------------- > > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 2/ Ability to simultaneously schedule M threads over N Processors. > 2A/ ability to tune and control the above.. > > 3/ One blocking thread cannot block another thread. > Blocking of one thread does not imply that other threads be > blocked. How about instead of 'cannot' we use the word 'does not necessarily' block another thread, and then append 'unless it does using programatic means'. Cannot implies some sort of bad thing. > 4/ All threads see the same address space (exactly). I like this. > 5/ All threads share the same file resources. How about 'process' resources instead? It's more than files that they share... > 10/ Quick access to curthread and thread specific data. We shouldn't > have to enter the kernel to get this. This should also be true > for threads spread across multiple [lightweight] processes. The last sentence is redundant, since threads are by definition lightweight processes. :) > 11/ Ability for the threads library to cancel/terminate a thread > blocked in the kernel. See previous email. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message