From owner-freebsd-hackers Tue Sep 16 01:22:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09554 for hackers-outgoing; Tue, 16 Sep 1997 01:22:38 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA09404 for ; Tue, 16 Sep 1997 01:22:08 -0700 (PDT) Received: (qmail 17763 invoked by uid 1000); 16 Sep 1997 08:20:57 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 16 Sep 1997 01:20:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Julian Elischer Subject: Re: What is wrong with this snipet? Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 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