From owner-freebsd-current Sun Nov 1 05:38:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA08203 for freebsd-current-outgoing; Sun, 1 Nov 1998 05:38:51 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA08197 for ; Sun, 1 Nov 1998 05:38:49 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA02419; Sun, 1 Nov 1998 08:38:39 -0500 (EST) Date: Sun, 1 Nov 1998 08:38:39 -0500 (EST) From: Daniel Eischen Message-Id: <199811011338.IAA02419@pcnet1.pcnet.com> To: jkh@time.cdrom.com, lists@tar.com Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Cc: current@FreeBSD.ORG, jb@cimlogic.com.au Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Seaman, Jr. wrote: > On Sat, 31 Oct 1998 14:08:43 -0800, Jordan K. Hubbard wrote: > > >I agree. While not perhaps adopting the perfect approach, at least > >Richard brings some very welcome *movement* to an issue which has been > >stalled for a regrettably long period of time. Let's try to run > >(cooperatively) with this and hopefully arrive at some working, > >architecturally clean kernel threads for FreeBSD! > > Just to be clear. I'm happy to co-operate and share code with anyone. > In fact, I'd be happy for someone else to just handle it all. In the > absence of someone else will to handle it all, I'm happy to contribute > what I can. > > The *only* reason I'd be hesitant to share any code at this moment > is that its still pretty messy, and I'd be embarrassed, and since > its barely tested, people would rightfully shoot all kinds of holes > in it. When its in a better state I'd be happy to post it somewhere > where anyone can whack at it. > I'd like to help in this effort, but I'd first like to see exactly what threading model is desired. Do we want a Solaris lightweight process model with the ability have both bound and unbound user threads? Or do we want libpthread to keep a one-one mapping of threads to kernel threads? After some decision on what direction kernel threads should take, we can then talk about the design and implementation. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message