Date: Mon, 23 Sep 1996 12:26:48 -0700 From: Julian Elischer <julian@whistle.com> 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) Message-ID: <3246E478.69D8BD19@whistle.com> References: <199609230808.AA175676096@ws2301.gud.siemens.co.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3246E478.69D8BD19>