From owner-freebsd-current Thu Sep 18 18:19:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA24732 for current-outgoing; Thu, 18 Sep 1997 18:19:28 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA24725; Thu, 18 Sep 1997 18:19:20 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id UAA00556; Thu, 18 Sep 1997 20:19:13 -0500 (EST) From: "John S. Dyson" Message-Id: <199709190119.UAA00556@dyson.iquest.net> Subject: Re: FYI: regarding our rfork(2) In-Reply-To: <199709190012.CAA11932@ocean.campus.luth.se> from Mikael Karpberg at "Sep 19, 97 02:12:33 am" To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Thu, 18 Sep 1997 20:19:13 -0500 (EST) Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg said: > According to John S. Dyson: > > I am going to be changing our rfork implementation in the following ways: > > > > Rename RFMEM to RFSHMEM, implying that we are fully sharing memory. > > Also implying that we don't support RFMEM in the same way as other > > OSes might. Add an additional argument to rfork(2) to support > > specifying a new stack address in the child. This argument is > > meaningful only if RFSHMEM is specified. This mod will eliminate > > some potential timing windows when the child is running with the > > parents stack. It will also eliminate the need for certain > > "gymnastics" in code that uses rfork with RFSHMEM. > > > > I'll be committing the changes tonight, so let me know if anyone > > has problems with the concept. > > Sounds good, but I as always I have some nosy questions out of > personal interest only: > > Is rfork() in any way portable enough to even consider keeping it happy > in porting software? Is it/should we try to keep it compatible with other > BSDs at least? > We are actually doing a pure memory sharing operation. We will be sharing everything, plan 9 doesn't appear to share the stack. In order to support pthreads, (and most thread schemes that I have seen), it is best to allow full access to all of the thread stacks. The 'full sharing' scheme is very fast. > > If so: > Would be be hard to do a "real" RFMEM too? (Probably not instantly since > it is wanted that things fall over from the lack of RFMEM if they are > using it. But when they are fixed.) > We could support the RFMEM as in Plan9, and IMO, that would be better from the standpoint of proper isolation of threads, but that isn't how threads are usually used. > > Will it be a problem for compilation if the new argument is not given, > or will it be a "..." argument, or something? > Shouldn't be a problem, it'll be like 'open(2)', where you can specify 2 or 3 args. > > Thanks for listening... :-) > No problem!!!! -- John dyson@freebsd.org jdyson@nc.com