bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Bruno Haible
Subject: Re: [PATCH replace vfork with fork] remove deprecated vfork
Date: Sun, 20 Nov 2022 12:47:42 +0100

Paul Eggert wrote:
> If future operating 
> systems remove vfork, the code will continue to work because HAVE_VFORK 
> won't be defined.

Yes. And the probability is low that future versions of existing operating
systems remove vfork, since
  - they need it for backward compatibility,
  - more than 700 Debian packages use vfork,
  - unlike 'gets', vfork is not a security issue.

Minsoo Choo wrote:
> 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%

Thanks for the pointer to this data. Indeed, it shows a clear performance win
gained by using vfork+exec instead of fork+exec.

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

I don't think it makes sense to compare them at this level. What's
expensive in fork() is the creation of the page tables for the new memory.
Therefore what needs to be measured is fork + exec + all the memory accesses
together.

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

Yes, that's a nice idea.

Paul Eggert wrote:
> We've run into another problem like this on macOS, where it incorrectly 
> complains about uses of sprintf. Perhaps Gnulib should simply use 
> -Wno-deprecated-declarations on macOS?

This would be too much, IMO. If macOS deprecates some functions like,
say, realpath or renameat, we _would_ want to know about it.


2022-11-20  Bruno Haible  <bruno@clisp.org>

        posix_spawn-internal: Avoid warning on macOS.
        Suggested by Minsoo Choo in
        <https://lists.gnu.org/archive/html/bug-gnulib/2022-11/msg00114.html>.
        * lib/spawni.c: Ignore -Wdeprecated-declarations warnings.

diff --git a/lib/spawni.c b/lib/spawni.c
index b3b3b56f31..a5081fd45b 100644
--- a/lib/spawni.c
+++ b/lib/spawni.c
@@ -854,6 +854,13 @@ __spawni (pid_t *pid, const char *prog_filename,
 #else
 
 
+/* The warning "warning: 'vfork' is deprecated: Use posix_spawn or fork" seen
+   on macOS 12 is pointless, as we use vfork only when it is safe or when the
+   user has explicitly requested it.  Silence this warning.  */
+#if __GNUC__ >= 3
+# pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+#endif
+
 /* Spawn a new process executing PATH with the attributes describes in *ATTRP.
    Before running the process perform the actions described in FILE-ACTIONS. */
 int






reply via email to

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