From owner-freebsd-hackers  Sat Feb  8 19:46:46 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id TAA23038
          for hackers-outgoing; Sat, 8 Feb 1997 19:46:46 -0800 (PST)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23033
          for <hackers@freebsd.org>; Sat, 8 Feb 1997 19:46:42 -0800 (PST)
Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id WAA07026; Sat, 8 Feb 1997 22:45:59 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199702090345.WAA07026@dyson.iquest.net>
Subject: Re: In what way are shared libs ``shared''?
To: proff@suburbia.net
Date: Sat, 8 Feb 1997 22:45:59 -0500 (EST)
Cc: toor@dyson.iquest.net, hackers@freebsd.org
In-Reply-To: <19970209032107.25671.qmail@suburbia.net> from "proff@suburbia.net" at Feb 9, 97 02:21:07 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > > My guess would be that this is due to writable statics in library code, so
> > > the library is shared, but copy-on-write.
> > > 
> > Note that alot of really broken VM systems immediately copy .data
> > in order to simplify the COW action.  We don't do that, and it
> > does complicate the code, but of course, shares more completely.
> > 
> > John
> > 
> 
> John, is it possible to force this behavior with rfork/mprotect?
> i.e if I rfork(RFPROC|RFMEM), and then do inet_ntoa(addr) in
> both parent and child, will the child COW the inet_ntoa static
> buffer, or will they collide?
> 
After a quick review of the code, the RFMEM
option will cause sharing of the address space (until the
parent or child changes theirs.)  In the case that you have
given, the child will not COW the page (and the memory
will be shared.)

The problem with RFMEM as it is implemented *right now*,
is that the parent's and child's address spaces will not
track.  This hurts the value of threading using rfork.
We will be (hopefully) supporting true address space
sharing soon (by correcting the semantics of RFMEM)
after the Lite/2 merge (which seems to have new
problems everytime I think that it is nearly done.)
The Lite/2 merge works now, and has been for
quite a while, but now the userland interfaces need
to be cleaned up (libs, etc.)

John