From owner-freebsd-current  Thu Sep 18 16:59:51 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA19081
          for current-outgoing; Thu, 18 Sep 1997 16:59:51 -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 QAA19062;
          Thu, 18 Sep 1997 16:59:35 -0700 (PDT)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.6/8.8.5) id SAA00339;
	Thu, 18 Sep 1997 18:59:25 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199709182359.SAA00339@dyson.iquest.net>
Subject: Re: FYI: regarding our rfork(2)
In-Reply-To: <3421B7C9.3F54BC7E@whistle.com> from Julian Elischer at "Sep 18, 97 04:22:49 pm"
To: julian@whistle.com (Julian Elischer)
Date: Thu, 18 Sep 1997 18:59:24 -0500 (EST)
Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG
Reply-To: dyson@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

Julian Elischer said:
> John S. Dyson wrote:
> > 
> > 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.
> 
> well, it makes it incompatible with the rfork in plan 9 
>
It is incompatible anyway, that is the reason that I am changing RFMEM
to RFSHMEM.  If we create a compatible RFMEM, then we can be compatible.

>
> What does  Linux's clone() call have as arguments..?
> 
I don't think that it makes any difference.  I am trying to solve a specific
problem with RF(SH)MEM that can be fixed a simple way (my proposal), or a
significantly more complex way, messing with signal masks, etc.

John
dyson@freebsd.org
jdyson@nc.com