Subject: Re: ddb & shared libs: second results
To: None <tech-kern@NetBSD.ORG, chuck@maria.wustl.edu>
From: None <jiho@postal.c-zone.net>
List: tech-kern
Date: 03/31/1998 18:22:25
On 30-Mar-98 jiho@mail.c-zone.net wrote:
> On 30-Mar-98 Chuck Cranor wrote:
>
>> anything that has "copy" inheritance will become copy-on-write at
>> fork(2) time. maybe that is what you are seeing?
I now definitely tend to think so.
I've tracked down the functions that do the dirty work: vm_map_copy_entry(),
which calls vm_object_copy(). Between the two of them, they account for the
behavior I'm seeing.
So, where does vm_map_copy_entry() get invoked from? For MAP_ANON mmaps, that
would seem to be exclusively from a fork, and then only because all map entries
are created VM_INHERIT_DEFAULT, which is defined as VM_INHERIT_COPY.
But offhand, I can't think of a GOOD way to avert that behavior in this older
Mach vm. In the general case, a process that has forked needs arbitrary access
(as child) to whatever it allocated before the fork (as parent), and you have
to assume you need to separate any changes to those allocations (parent changes
versus child changes). You can tentatively assume the changes can be shared
in the mundane case, where the process forks simply to do an exec, but even
that assumption is dangerous.
It's a real square peg in a round hole. But at least now I _think_ I finally
understand it....
--Jim Howard <jiho@mail.c-zone.net>
----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 31-Mar-98
Time: 18:22:25
This message was sent by XFMail
----------------------------------