Date: Sat, 8 Feb 1997 22:45:59 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: proff@suburbia.net Cc: toor@dyson.iquest.net, hackers@freebsd.org Subject: Re: In what way are shared libs ``shared''? Message-ID: <199702090345.WAA07026@dyson.iquest.net> In-Reply-To: <19970209032107.25671.qmail@suburbia.net> from "proff@suburbia.net" at Feb 9, 97 02:21:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702090345.WAA07026>