From owner-freebsd-current Thu Sep 18 15:35:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13356 for current-outgoing; Thu, 18 Sep 1997 15:35:39 -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 PAA13343 for ; Thu, 18 Sep 1997 15:35:35 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id RAA09701 for current@freebsd.org.; Thu, 18 Sep 1997 17:35:33 -0500 (EST) From: "John S. Dyson" Message-Id: <199709182235.RAA09701@dyson.iquest.net> Subject: FYI: regarding our rfork(2) To: current@freebsd.org Date: Thu, 18 Sep 1997 17:35:33 -0500 (EST) 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 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. -- John dyson@freebsd.org jdyson@nc.com