Re: vfork revisited (was 64bit clean XEmacs)
Colin Rafferty wrote:
> Why not have an exec-like call which creates a new process
(instead of
> replacing the current one with the new one)?
We already have that. Call system() with a `&' at the end of the
command string.
Almost, but not quite. system() needs to change the signal disposition
between the (v)fork() and the exec().
On platforms which don't overcommit, the fork() might fail with
ENOMEM, so you would like to use vfork() instead. However, system()
needs to change the signal disposition, and (AFAIK) you can't
guarantee being able to call sigaction() etc following vfork() on all
platforms. On a platform where you can't, system() would have to be
implemented using fork(), which could fail if it doesn't overcommit.
OTOH, a bare-bones vfork()/exec() without changing the signal
disposition isn't really much use.
Ultimately, this is only an issue on platforms which both:
a) don't overcommit, and
b) don't allow certain useful functions to be safely called between a
vfork() and an exec().
As Georg pointed out:
The bug that Solaris had until 2.6 was that the signal disposition
wasn't handled correctly because a lot of the signal junk is actually
contained within libc data area (dynamic) and thus part of the address
space. So, when a child diddled signal stuff, it actually wacked the
parents stuff. Again, this has been fixed since 2.6.
so such systems would appear to exist.
Also, XEmacs' use of fork() is in situations more akin to popen(),
where it is also necessary to use e.g. dup2() to set up pipes.
For the benefit of platforms which don't overcommit, it would be
useful to figure out what we call between fork() and exec(), so that
vfork() can be used instead where possible.
--
Glynn Clements <glynn(a)sensei.co.uk>