Date: Tue, 16 Sep 1997 00:30:50 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: Jason Thorpe <thorpej@nas.nasa.gov>, freebsd-hackers@FreeBSD.ORG Subject: Re: What is wrong with this snipet? Message-ID: <Pine.BSF.3.95.970916002218.13496A-100000@current1.whistle.com> In-Reply-To: <XFMail.970915213646.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.. 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. julian > > --- > > > Sincerely Yours, (Sent on 15-Sep-97, 21:20: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?Pine.BSF.3.95.970916002218.13496A-100000>