From owner-freebsd-arch Sun Oct 31 18:59:37 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 1B9CB14FFD for ; Sun, 31 Oct 1999 18:59: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 DAA01623 for ; Mon, 1 Nov 1999 03:59:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69619 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:59:30 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 6D2F5150A7 for ; Sun, 31 Oct 1999 18:59:05 -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 SAA30861; Sun, 31 Oct 1999 18:59:02 -0800 (PST) Date: Sun, 31 Oct 1999 18:58:59 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Nate Williams Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II In-Reply-To: <199911010225.TAA14010@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: > > ---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. I'm trying to say that "just because one thread blocks, doesn't mean that the others can't keep running"! Will that do? > > > 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... 4/ All threads in a processs see the same address space (exactly). 5/ All threads in a process share the same system resources. > > 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. :) 10/ Quick access to curthread and thread specific data. > > > 11/ Ability for the threads library to cancel/terminate a thread > > blocked in the kernel. > > See previous email. See previous clarification.. :-) I think a way to ask a thread to 'wake up and back out' is what's required. > > > > Nate > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message