Date: Tue, 16 Sep 1997 01:20:56 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Julian Elischer <julian@whistle.com> Cc: Jason Thorpe <thorpej@nas.nasa.gov>, freebsd-hackers@FreeBSD.ORG Subject: Re: What is wrong with this snipet? Message-ID: <XFMail.970916012056.Shimon@i-Connect.Net> In-Reply-To: <Pine.BSF.3.95.970916002218.13496A-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Julian Elischer; On 16-Sep-97 you wrote: > > > On Mon, 15 Sep 1997, Simon Shapiro wrote: > > > > > Hi Jason Thorpe; On 14-Sep-97 you wrote: > > > On Sat, 13 Sep 1997 16:34:42 -0700 (PDT) > > > Simon Shapiro <Shimon@i-Connect.Net> wrote: > > > > > > > Why would the following segfault on 6 of the 10 iterations? > > > > > > In the FreeBSD implementation of RFMEM (which does not match Plan > > > 9's), > > > the child gets the same stack as the parent. If you "return" in the > > > child, > > > someone's stack gets munched. > > > > Not exactly useful, I'd say... > I beg to dissagree. it does exactly what it says it does.. > "Share entire address space" > How are you going to share address spaces if you don't share the stack.. > last time I looked the stack was a part of the address space. > The aim of this is the same as the Linux CLONE() call. The processes > with shared address spaces look to all the world the same as two > threads > in the same process. Obviously, multiple threads in the same process > can see each other's stacks etc, and various 'threads' in a > process can 'migrate' to the other process if all shared > processes can see all the stacks.. My apologies. Again, I am not clear in my words. I have no qualm, nor argument with the definition, not necessarily with the implementation. >From my naive point of view, what is less than very useful is the fact that one process exiting blows up the other which is not. One would think that since all processes now share the same address space, early exiters do not take the memory with them, but leave it for the others. > The secret is to allocate a new stack before the rfork() for the > child, and make sure that it does a longjmp() to it > the moment that it returns, leaving the stack uncorrupted for > the returning parent. Usually this is all hidden inside a library > routine called thread_fork() or similar. rfork() just supplies the > mechanism. >From my thinking (which is not necessarily correct), instead of new processes having to identify to themselves that they are new, and worry about securing pieces of their legitimate address space, the ones who leave the party do not take the lightbulbs, the food and the keg with them. Being that I never drink and rarely ``party'', I may be wrong :-) --- Sincerely Yours, (Sent on 16-Sep-97, 01:14:55 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970916012056.Shimon>