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 <tho...@schwinge.name>wrote: > Hallo! > > On Thu, 24 Nov 2011 15:59:55 -0000, Planet GNU <tschwinge+n...@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 >
