From owner-freebsd-hackers  Mon Sep 23 12:32:49 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA06175
          for hackers-outgoing; Mon, 23 Sep 1996 12:32:49 -0700 (PDT)
Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA06139
          for <freebsd-hackers@FreeBSD.org>; Mon, 23 Sep 1996 12:32:45 -0700 (PDT)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id MAA03241; Mon, 23 Sep 1996 12:28:28 -0700 (PDT)
Message-ID: <3246E478.69D8BD19@whistle.com>
Date: Mon, 23 Sep 1996 12:26:48 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: "Hr.Ladavac" <lada@ws2301.gud.siemens.co.at>
CC: Terry Lambert <terry@lambert.org>, michaelh@cet.co.jp,
        freebsd-hackers@FreeBSD.org
Subject: Re: thread stacks and protections (was Re: attribute/inode caching)
References: <199609230808.AA175676096@ws2301.gud.siemens.co.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Hr.Ladavac wrote:
> 
> E-mail message from Terry Lambert contained:
> >

> 
> I have a problem with thread stacks in separate VM spaces.  This, namely,
> means that an RPC call that doesn't leave the process space cannot be
> fully optimized away because I can not use auto variables as my
> result areas without an additional copy.  Same applies to the [in]
> arguments, as well.
> 
> What I want to say is that one thread cannot pass another thread an
> address to an object on its stack.
> 
> This is probably worth considering during design.

I agree that it should be possible for threads to see each other's
stacks, however it
should also not be commonly used as threads shoul dnot look at items 
on each others stacks because tehre is no guarantee that hte 
other  thread has not reqound it's stack back beyond that point..
of course, shared stacks is much quicker from a context point of view,
and some threads packages use the top bits of the stack pointer 
as the index of the thread..
e.g. sp & 0xfff00000 is the  thread number.

has 
> 
> /Marino