From owner-freebsd-current  Fri Sep 19 09:05:34 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA20959
          for current-outgoing; Fri, 19 Sep 1997 09:05:34 -0700 (PDT)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20941;
          Fri, 19 Sep 1997 09:05:20 -0700 (PDT)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id KAA17322;
	Fri, 19 Sep 1997 10:04:19 -0600 (MDT)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA19167; Fri, 19 Sep 1997 10:04:17 -0600 (MDT)
Date: Fri, 19 Sep 1997 10:04:17 -0600 (MDT)
Message-Id: <199709191604.KAA19167@rocky.mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: dyson@freebsd.org
Cc: nate@mt.sri.com (Nate Williams), karpen@ocean.campus.luth.se,
        current@freebsd.org
Subject: Re: FYI: regarding our rfork(2)
In-Reply-To: <199709190610.BAA00804@dyson.iquest.net>
References: <199709190518.XAA16454@rocky.mt.sri.com>
	<199709190610.BAA00804@dyson.iquest.net>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

John S. Dyson writes:
[ New shared everything call being added ]

I wrote:
> > it seems that sharing the stack
> > is asking for nothing but trouble.

John responds:

> I don't disagree with what you are saying, however, we need to be able
> to have full access to the stacks in every thread.  Of course, we would
> be wise to create guard page(s) between stacks.

Why do we need to have access to the stack?  Is it *only* for the thread
'kernel' that runs in user-land that does the 'context-switching'
between the threads, or will each thread have access to another thread's
stack.  I can definitely see the need for the former, but *NOT* the
latter.

The great strength about Unix is that another 'process' can'tt muck with
another 'processes' easily, and with threads I'd like to see this taken
to whatever extreme as possible given the constraints of implementation.


Nate