Re: GNUnet News: vfork and the signal race
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? 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. (Naturally, the result would be non-portable for systems where fork==vfork, but then maybe implementing vfork as fork is the bug? ;-)) Happy hacking Christian
Re: GNUnet News: vfork and the signal race
Oh, and in the case you describe there: The hypervisor at start creates a global variable hypervisor_pid, initialized from getpid(). The signal handler in the hypervisor then does this: if getpid() == hypervisor_pid kill_all_children_and_exit(); else exit(); In this way, if the child is between fork and exec when the parent gets its kill, and then it tries to kill the child, and the kill happens before the child execs (the problematic case you describe), then the child simply enters the hypervisor's signal handler, notices that it's not the hypervisor, and exits. Thomas On Fri, Nov 25, 2011 at 4:09 PM, Christian Grothoff wrote: > 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? 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. (Naturally, the result would be non-portable for systems > where fork==vfork, but then maybe implementing vfork as fork is the bug? > ;-)) > > Happy hacking > > Christian >
Re: GNUnet News: vfork and the signal race
The original BSD man page warned that the behavior should not be relied on. Thomas On Nov 25, 2011 4:10 PM, "Christian Grothoff" wrote: > 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? 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. (Naturally, the result would be non-portable for systems > where fork==vfork, but then maybe implementing vfork as fork is the bug? > ;-)) > > Happy hacking > > Christian >
Re: GNUnet News: vfork and the signal race
Programs which depend on the special suspend-the-parent behavior of vfork
were always regarded as buggy...
Thomas
On Fri, Nov 25, 2011 at 7:42 AM, Thomas Schwinge wrote:
> Hallo!
>
> On Thu, 24 Nov 2011 15:59:55 -, Planet GNU
> wrote:
> > Many articles uniformly claim that using vfork should be
> > [avoided][1] and that the only difference between vfork and fork is (or
> > used-to-be) [performance][2] and that thus vfork is [obsolte][3]. Here, I
> > wanted to document a technical case where vfork is actually required and
> > where using vfork instead of fork (or operating system implementors
> > implementing vfork as an alias for fork) causes a hard-to-find data race.
> > [...]
> > URL: https://gnunet.org/vfork
>
> Rather ``using *fork* instead of *vfork*'', I assume?
>
>
> Just for the record, the Hurd doesn't have a vfork implementation, and
> we're thus using glibc's default POSIX vfork implementation:
>
>/* If we don't have vfork, fork is close enough. */
>
>__pid_t
>__vfork (void)
>{
> return __fork ();
>}
>
> I wonder how clumsy it would get to add vfork's ``parent blocks until the
> child calls _exit or exec'' functionality.
>
>
> Grüße,
> Thomas
>
Re: GNUnet News: vfork and the signal race
Hallo!
On Thu, 24 Nov 2011 15:59:55 -, Planet GNU wrote:
> Many articles uniformly claim that using vfork should be
> [avoided][1] and that the only difference between vfork and fork is (or
> used-to-be) [performance][2] and that thus vfork is [obsolte][3]. Here, I
> wanted to document a technical case where vfork is actually required and
> where using vfork instead of fork (or operating system implementors
> implementing vfork as an alias for fork) causes a hard-to-find data race.
> [...]
> URL: https://gnunet.org/vfork
Rather ``using *fork* instead of *vfork*'', I assume?
Just for the record, the Hurd doesn't have a vfork implementation, and
we're thus using glibc's default POSIX vfork implementation:
/* If we don't have vfork, fork is close enough. */
__pid_t
__vfork (void)
{
return __fork ();
}
I wonder how clumsy it would get to add vfork's ``parent blocks until the
child calls _exit or exec'' functionality.
Grüße,
Thomas
pgpYoE44JKDua.pgp
Description: PGP signature
