From owner-freebsd-current  Thu Sep 18 23:47:31 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18474
          for current-outgoing; Thu, 18 Sep 1997 23:47:31 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18464;
          Thu, 18 Sep 1997 23:47:24 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id XAA20281;
	Thu, 18 Sep 1997 23:39:22 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd020279; Fri Sep 19 06:39:17 1997
Date: Thu, 18 Sep 1997 23:38:33 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: Nate Williams <nate@mt.sri.com>
cc: "John S. Dyson" <toor@dyson.iquest.net>,
        Mikael Karpberg <karpen@ocean.campus.luth.se>, dyson@FreeBSD.ORG,
        current@FreeBSD.ORG
Subject: Re: FYI: regarding our rfork(2)
In-Reply-To: <199709190518.XAA16454@rocky.mt.sri.com>
Message-ID: <Pine.BSF.3.95.970918233609.1895G-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


All the processes running the threads need to be able to see all the
stacks because the threads can migrate between the processes. Remember,
we are trying to emulate threads running in a single address
space/process,
so we need to share ALL of the address space..


On Thu, 18 Sep 1997, Nate Williams wrote:

> > We are actually doing a pure memory sharing operation.  We will be sharing
> > everything, plan 9 doesn't appear to share the stack.  In order to support
> > pthreads, (and most thread schemes that I have seen), it is best to allow
> > full access to all of the thread stacks.
> 
> Forgive me for being naive, but in all of my experiences with threads
> (not much, but lots lately with Java), it seems that sharing the stack
> is asking for nothing but trouble.  If you need to share memory,
> allocate a 'global' shared memory bank that everyone can use, and use
> it.
> 
> From where I stand, sharing thread's stacks buys you nothing but
> problems worse than the malloc/free problems we're talking about. :(
> 
> (I've got enough problems with the stupid race conditions with AWT in
> Java.)
> 
> 
> 
> Nate
>