Re: GNUnet News: vfork and the signal race

[Samuel Thibault]

Christian Grothoff, le Sat 26 Nov 2011 01:09:59 +0100, a écrit :
> On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote:
> >Programs which depend on the special suspend-the-parent behavior of
> >vfork were always regarded as buggy...
> 
> So relying on the well-documented behavior of a system call is a bug?

A documentation is not a norm. The norm only says that it "shall be
equivalent to fork(), except that the behavior is undefined if the
process created by vfork() either modifies any data other than a
variable of type pid_t used to store the return value from vfork(), or
returns from the function in which vfork() was called, or calls any
other function before successfully calling _exit() or one of the exec
family of functions."

Relying on some OS documentation makes you out of portability, it's the
norm that matters for portability. Posix has actually even just dropped
the function from its standard, so using vfork is now not even standard
according to POSIX 2008.

> Did
> you even read about the scenario I described at
> https://gnunet.org/vfork ? Before writing this, I looked around for existing
> information on vfork, but I didn't find anyone making a good argument (or
> even the claim) that relying on 'suspend-the-parent' was per-se buggy.

Nothing in the POSIX norm says that the parent is suspended.

> (Naturally, the result would be non-portable for systems where fork==vfork,
> but then maybe implementing vfork as fork is the bug? ;-))

It's what the norm says.

Now, about the problem you mention on the webpage, isn't it possible to
use a semaphore to tell the hypervisor when the "just-forked" process
has changed its signal handler for something that is fine with SIGTERM?
Or use a signal back (IIRC Xorg does this). That would implement the
"make father wait" in a portable way.

Samuel