Re: [PATCH replace vfork with fork] remove deprecated vfork

[Bruno Haible]

Hi Minsoo,

Minsoo Choo wrote:
> I highly suggest to replace vfork(2) with fork(2) for several reasons.
> First, some systems like macOS have deprecated vfork(2) and encourage
> users to use fork(2).

References, please?

> This can cause compatibility issues in the future
> which will bring build errors on some systems.

References, please? In 
<https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/vfork.2.html>
I read
  "This system call will be eliminated when proper system sharing mechanisms
   are implemented.  Users should not depend on the memory sharing semantics
   of vfork as it will, in that case, be made synonymous to fork."
which indicates that using vfork() without relying on the memory sharing *is*
future-proof.

> Furthermore, although I
> acknowledge the advantages of using vfork(2), many programmers have
> criticized that it is a dangerous practice to use it, and I agree with
> that idea.

You are not showing an indication that Gnulib uses it in a dangerous way.
And Gnulib also does not open up this library call to users: it does not
provide a module 'vfork'; it merely provides modules 'posix_spawn' and
'posix_spawnp'.

> The implementation of fork(2) has been improved on many
> operating systems including Linux

But Gnulib cares about other operating systems as well — from Solaris to
Cygwin.

> therefore I believe that the huge gap between
> the performances of vfork(2) and fork(2) does not exist anymore.

This means, you have not made performance measurements yourself?

Sorry, your point is not convincing:

* Gnulib, like many other GNU packages, attempts a balance between
  safety and efficiency/performance. (If we were not striving for
  efficiency, we would be writing all programs in Python or Java, not
  in C.) You need to convince us that we did a mistake by relying
  *too much* on the efficiency side. Your generic talk didn't prove
  anything. Instead, what would be convincing is a test case where you
  show "this test case that uses posix_spawn operates unreliably".

* The code in lib/spawni.c uses vfork() if and only if
    (1) nothing complicated happens between vfork() and exec(), or
    (2) the user has passed the flag POSIX_SPAWN_USEVFORK.
  If we have made a mistake in the condition (1), please highlight it
  and we will fix it.
  In case (2) the caller has requested the use of vfork(). In C a
  programmer can shoot themselves in the knee; likewise here, but it's
  the responsibility of the caller.

Finally, if you a distro guy and want to enforce some policy, you can
do so by setting the environment variable
  ac_cv_func_vfork=no
while configuring the packages that use Gnulib. So, this use-case does
not require changing Gnulib either.

Bruno