Date: Tue, 30 Nov 1999 07:19:09 +1100 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: Peter Wemm <peter@netplex.com.au> Cc: arch@freebsd.org Subject: Re: Threads stuff - reality check.. Message-ID: <99Nov30.071153est.40325@border.alcanet.com.au> In-Reply-To: <19991129144125.C7E121CC6@overcee.netplex.com.au> References: <19991129144125.C7E121CC6@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Nov30.071153est.40325>