From owner-freebsd-arch Mon Nov 29 22:45:39 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 7A9F715792 for ; Mon, 29 Nov 1999 22:45:36 -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 HAA29018 for ; Tue, 30 Nov 1999 07:45:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA68836 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 07:45:36 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 68EBB15792 for ; Mon, 29 Nov 1999 22:45:29 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id WAA74907 for ; Mon, 29 Nov 1999 22:45:28 -0800 (PST) Date: Mon, 29 Nov 1999 22:45:28 -0800 (PST) From: Julian Elischer To: freebsd-arch@freebsd.org Subject: Revisitted.. Threads goals.? In-Reply-To: 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 I think this is a good time for us to re-examine some of the things that we decided were goals. I have somme comments I'd like to make AT THE END, but after the general neuron frying of the last week or so it might be a good idea to look at these again and see if any of them have changed in light of the discussion. I have difficulty in seeing this list as exhaustive or correct. We need someone who is very into threads to contribute. Jason? What do yuo see as YOUR goals? -----last version of the goals I have in my mailbox.---- 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, and have min(M,N) threads simultaneously executing. 2A/ ability to tune and control the above.. 3/ Just because one thread blocks, doesn't mean that the others can't keep running. 4/ All threads in a processs see the same address space (exactly). 4A/ All threads in a process share the same system resources, except cpu which is treated specially, and some as yet unspecified thread specific uniqifier. 5/ A process may be able to group threads into classes that have different system priorities. These classes can not have priorities greater than the process itself or a child could achieve, and should be treatable by the system as a separate child process from a scheduling point of view (including limits). 5A/ As a result threaded processes should have no more capability to swamp a system than a regular forking process. 6/ Some well documeted scheme exists for handling signals and other async events. 7/ Exit/shutdown protocol is well defined. 8/ The allocation of user level threads to thread groups is opaque to the kernel. 9/ Quick access to curthread and thread specific data. 10/ A method to ask a thread blocked in the kernel to wake up and back out (similar to present 'signals'). (see 6, 7) ---- possible userland implementation goals----- 1/ A libpthread that can be linked with libc. 2/ Libc needs to change so that library functions and system calls used internal to the library do not use the externally visible cancellable equivalents. 3/ see 8 above. ------------- Meta-goals ------------- We should keep our eyes on: *) scalability *) performance *) ability to support features required by standards based threads. *) ability to support features of those thread packages we select as needed. --------------------------- COMMENTS: Peter made a valid point which is that maybe we should figure out a waypoint between here and there, that gives us a working but sub-optimal threads package of the order of the linux threads package, that can be included in 4.0 We may have 2 whole months to get that done :-( Also, Matt Dillon has been arguing strongly that point 8 (kernel) and point 3(user) are non goals, in fact he wants the opposite. He also argues that making an entity that groups KSE's on a scale smaller than the entire process is a bad idea. I disagree but we haven't decided anyting yet. He claims 'simplicity. I think that he may be sliding back up teh other side of th ecurve by trying to simplify more than the goals (many of which we are inherritting from Posix via the 3rd meta-goal) allow. how would we move towards Peter's hope? and are there things we can do that there is no argument about? I think that separating the proc structure is agreed, but it is not needed for Linux threads.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message