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: Thomas Schwinge
Subject: Re: GNUnet News: vfork and the signal race
Date: Fri, 25 Nov 2011 16:42:59 +0100
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)

Hallo!

On Thu, 24 Nov 2011 15:59:55 -0000, Planet GNU <tschwinge+news@gnu.org> 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

Attachment: pgpk6XIUqGRWo.pgp
Description: PGP signature


reply via email to

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