Re: vfork revisited (was 64bit clean XEmacs)
Justin Vallon wrote:
> > When a UNIX process wants to create a child, it fork()s and
exec()s.
> > The fork() duplicates the parent's address space. This was seen as
> > silly when 9 times out of 10 the child simply calls exec and thus was
> > born vfork(). vfork() has this problem, though that the child briefly
> > runs in the parents address space. The implications of this statement
> > are serious and have resulted in two things. First, standards authors
> > have had no choice but to say that you can't guarantee anything aside
> > from exec() or _exit() will work. Second, application developers have
> > been bitten by all kinds of nasty bugs and have shied away from vfork.
> > The net result is that vfork() could probably be removed from the UNIX
> > ABI and nobody would shed a tear.
M-: (douse fire)
So, if your OS (Solaris?) does not overcommit vm pages, then at fork()
time, free swap pages will be earmarked as potentially required if the
process(es) write to all of their shared pages?
Yep.
Since the parent has a 100Mb swap footprint, you'll basically
need
100Mb free swap to be able to do {fork();exec();} due to the
high-water-mark,
Yep.
even though no (few) shared pages will ever be copied-due-to-write.
But you can't know that this will be the case at the time that fork()
was called; the child might not call exec().
If you get around the problem by overcommitting, then you are left
with a child process which can die suddenly just because it wrote to
one page too many. This isn't a good idea if you want to write robust
programs.
The solution is to provide a usable vfork(), i.e. one where you can
guarantee being able to perform a minimal set of useful operations
between the vfork() and the exec(). dup2() is an obvious candidate;
signal handling would also be pretty high on the list.
--
Glynn Clements <glynn(a)sensei.co.uk>