From owner-freebsd-arch Mon Nov 29 12:19: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 F1B2914E03 for ; Mon, 29 Nov 1999 12:19:32 -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 VAA23508 for ; Mon, 29 Nov 1999 21:19:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA65906 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 21:19:25 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id A38B214E03 for ; Mon, 29 Nov 1999 12:19:14 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Tue, 30 Nov 1999 07:11:53 +1100 Content-return: prohibited Date: Tue, 30 Nov 1999 07:19:09 +1100 From: Peter Jeremy Subject: Re: Threads stuff - reality check.. In-reply-to: <19991129144125.C7E121CC6@overcee.netplex.com.au> To: Peter Wemm Cc: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov30.071153est.40325@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991129144125.C7E121CC6@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-30 01:41:25 +1100, Peter Wemm wrote: >I'd hate to ruin a good pie-in-the-sky session on the design of the >killer threads system and all, but I kinda wonder if we're aiming too >hight to start with? Maybe... >Wouldn't it be better to put the pieces that we already have together and >make something in time for 4.0 that runs with better concurrency than we >have now? I _would_ like to see something make it into 4.0. I would also like to be reasonably sure that whatever we initially put into 4.0 can evolve into the final design as visualised by Julian, Daniel et al. As I understand it, this means that we need to have an `interim' threads implementation that has pretty much the same user API and kernel interface as our target (since the interfaces can't change until 5.0). I believe we're allowed to undertake a major re-work of the underlying code as long as the interfaces don't change. That suggests that our priorities need to be: 1) What user API do we want? I think there is general concensus that we need to use the same API as "everyone else" (pthread aka IEEE POSIX 1003.1c-1995). 2) What kernel interface do we need? This is still the subject of much discussion. In particular, it's not clear whether the thread scheduler should be in the kernel, userland or split between them in some manner. If we can agree on a suitably extensible kernel interface (which basically means that the copyin and copyout structures both begin with a version and size), we might be able to sneak through a substantial interface change without objections. 3) Do we have some interim code that can meet 1 and 2 and be committed before the feature freeze? Peter suggested Richard's native linuxthreads port. I can't somment on it's suitability. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message