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

[Minsoo Choo]

Hi Bruno,

vfork(2) is removed on Single Unix Specifiction Issue 7, 2018 Edition. 
<https://publications.opengroup.org/c181>
"vfork() Applications are recommended to use the fork() function instead of 
this function. The vfork() function was previously under-specified."

This means that future UNIX operating systems might not have vfork(2) even if 
they are certificated by the Open Group.

vfork(2) is deprecated or is not encouraged to be used on several systems, and 
these are the references for them.

>From vfork(2) from macOS 13.0.1 (I could not find one online)

"vfork – deprecated system call to create a new process (...)
As of macOS 12.0, this system call behaves identically to the
fork(2) system call, except without
calling any handlers registered with pthread_atfork(2).
This system call is deprecated. In a future release, it may 
begin to return errors in all cases, or may be removed 
entirely.  It is extremely strongly recommended
to replace all uses with fork(2) or, ideally, posix_spawn(3)."

>From vfork(2) from FreeBSD 13.1
<https://www.freebsd.org/cgi/man.cgi?query=vfork&manpath=FreeBSD+13.1-RELEASE+and+Ports>

"Since this function is hard to use correctly from application
software, it is recommended to use posix_spawn(3) or    fork(2) 
instead."

>From vfork(2) from illumos (which is a derivative of OpenSolaris)
<https://illumos.org/man/2/vfork>

"The vfork() and vforkx() functions are deprecated. (...) The 
vfork() function is Obsolete Standard."


For the performance test, I got following result on Linux.
(vfork(2) is replaced by fork(2) on macOS)

- Tested on VMware Fusion 12, Kali Linux, 6 core/8GB RAM

- I used this tool on Github: <https://github.com/famzah/popen-noshell>

Test result on 2009: 
<https://blog.famzah.net/2009/11/20/a-much-faster-popen-and-system-implementation-for-linux/>
Memory 20MB, ratio 1:1

Test result on 2018: 
<https://blog.famzah.net/2018/12/19/posix_spawn-performance-benchmarks-and-usage-examples/>
Memory: 200MB, ratio 1:2

My test result on 2022:
Memory: 200MB, ratio 1:2, count 200000

fork() + exec():
real: 50.46s
user: 32.96s
sys: 18.40s
cpu: 101%

vfork() + exec():
real: 28.53s
user: 23.00s
sys: 11.04s
cpu: 119%


On 2009, the performance ratio of vfork and fork was 8.107.
On 2018, fork was 836% slower than vfork.
On 2022, the performance ratio of vfork and fork is 1.769.

However, if we really need to use vfork, we can apply

# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wdeprecated-declarations"
...
# pragma GCC diagnostic pop

to ensure to the users that our vfork is safe.


Minsoo


------- Original Message -------
On Saturday, November 19th, 2022 at 5:10 PM, Bruno Haible <bruno@clisp.org> 
wrote:


> 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
>