bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUnet News: vfork and the signal race


From: Christian Grothoff
Subject: Re: GNUnet News: vfork and the signal race
Date: Sat, 26 Nov 2011 15:53:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111004 Lightning/1.0b1 Icedove/3.0.11

Thank you Thomas for your suggestion. For our purposes, this is a better (certainly more portable) solution that does always work.

Happy hacking,

Christian

On 11/26/2011 02:43 AM, Thomas Bushnell, BSG wrote:
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
<christian@grothoff.org <mailto:christian@grothoff.org>> 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]