From owner-freebsd-hackers  Sat Feb  8 13:35:40 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA01285
          for hackers-outgoing; Sat, 8 Feb 1997 13:35:40 -0800 (PST)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01276
          for <hackers@FreeBSD.ORG>; Sat, 8 Feb 1997 13:35:33 -0800 (PST)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA09446; Sat, 8 Feb 1997 13:34:58 -0800 (PST)
Received: from alpo.whistle.com(207.76.205.1) by whistle.com via smap (V1.3)
	id sma009444; Sat Feb  8 13:34:47 1997
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22])
          by alpo.whistle.com (8.8.5/8.8.4) with SMTP
	  id NAA21559; Sat, 8 Feb 1997 13:35:28 -0800 (PST)
Message-ID: <32FCF0FA.446B9B3D@whistle.com>
Date: Sat, 08 Feb 1997 13:32:42 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: "John S. Dyson" <toor@dyson.iquest.net>
CC: Craig Shaver <craig@progroup.com>, hackers@FreeBSD.ORG
Subject: Re: fcntl, F_SETFL, O_NONBLOCK & /dev/null
References: <199702080220.VAA14428@dyson.iquest.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

John S. Dyson wrote:
> 
> >
> > Is there any work being done for implementing kernel threads?  I would
> > think this would be very important for a robust, real-world usable,
> > thread package.
> >
> That is one of my interests.  Doug Santry is also interested.  Certainly
> don't want to 'claim' the project until I start.  I have some ideas,
> and in conjunction with some of Doug's work, I think that we could
> have a really good thread's capability.  I have a VM experiment to
> do first (relocatable kernel stack, totally shared VM space.)  If
> that works, we'll have a start on a really good mechanism.

YES!

that is the crucial point..
(though there are questions about what to do about thread
signal handlers)

making rfork(SHAREED_VM) work is the first important step
that should make 
rfork(RFMEM|RFPROC) blindingly fast ..

MACH simply allocated a separate kernel stack for each
process, with a guard page.. (touch it and the process dies)