aeusesef@csun.UUCP (04/10/87)
[]
In systems which use a virtual-memory version of fork (e.g., vfork in BSD),
how is the stack treated? That is, since the basic purpose of vfork was to
allow two processes to use the same code and data spaces, until one of them
changed some part of the data (usually with an exec()) using a COPY-ON-WRITE
feature of the virtual memory handler (if available), then doesn't the exec
call force a copy of the data space, since it forces data onto the stack?
(Not being very terse, am I?)
Anyway, I would appreciate any help anybody out there could give me.
Thank you for your support.
-----
Sean Eric Fagan ------\
Computer Center litvax \
Cal State University, Northridge rdlvax \
18111 Nordhoff St. psivax --> !csun!aeusesef
Northridge, CA 91330 hplabs /
AGTLSEF@CALSTATE.BITNET ihnp4 /
------/
"I drank what?!" -- Socrates | My opinions *are* facts.guy@gorodish.UUCP (04/10/87)
>In systems which use a virtual-memory version of fork (e.g., vfork in BSD), >how is the stack treated? That is, since the basic purpose of vfork was to >allow two processes to use the same code and data spaces, until one of them >changed some part of the data (usually with an exec()) using a COPY-ON-WRITE >feature of the virtual memory handler (if available), No, "vfork" puts the parent process "on hold" until the child process relinquishes its current address space, either by exiting or by doing an "exec". No copying is done. In some ways the purpose of "vfork" was to provide an efficient form of "fork" for systems where a copy-on-write feature *wasn't* provided by the virtual memory code. >then doesn't the exec call force a copy of the data space, since it forces >data onto the stack? Not unless you have implemented copy-on-write on a system where you can't write-protect individual pages. If you can write-protect individual pages, the "exec" call will only touch a couple of pages of the stack, and those are the only ones that will be copied.