From owner-freebsd-current  Fri Sep 19 11:48:52 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA00386
          for current-outgoing; Fri, 19 Sep 1997 11:48:52 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA00373;
          Fri, 19 Sep 1997 11:48:34 -0700 (PDT)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.6/8.8.5) id NAA02645;
	Fri, 19 Sep 1997 13:48:22 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199709191848.NAA02645@dyson.iquest.net>
Subject: Re: FYI: regarding our rfork(2)
In-Reply-To: <199709191604.KAA19167@rocky.mt.sri.com> from Nate Williams at "Sep 19, 97 10:04:17 am"
To: nate@mt.sri.com (Nate Williams)
Date: Fri, 19 Sep 1997 13:48:22 -0500 (EST)
Cc: dyson@FreeBSD.ORG, nate@mt.sri.com, karpen@ocean.campus.luth.se,
        current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Nate Williams said:
> 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.
>
Actually, both need it.  Otherwise, we will be incompatible with the rest
of the world.

> 
> 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.
> 
The threads are a different issue.  I don't disagree with the threads stacks being
isolated for philosophical reasons -- however it is just wrong from a compatibility
standpoint.

If we had a type of thread that had isolated stacks, it would be nice, but that
is a different exercise.


-- 
John
dyson@freebsd.org
jdyson@nc.com