Red Hat Bugzilla – Bug 131938
posix_spawn implementation inquiry (why fork/exec rather than vfork/exec).
Last modified: 2017-09-16 02:20:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b)
Gecko/20030516 Mozilla Firebird/0.6
Description of problem:
This is more of a request for information item rather
than an actual bug item.
The glibc version of posix_spawn (as used in RH Enterprise
Linux 3) is implemented via fork/execve (I looked at the
glibc source code).
That is fine for the most part. However if one manages
to create a large process with an extremely large
number of memory mapped regions then consequently
fork/exec performance degrades badly. I have confirmed
this with a simple test case. The vfork function which
does not copy the page table entries from the parent to
the child process does not suffer from the same performance
Solaris 10 now comes with a posix_spawn implementation.
Using truss and speaking with Solaris engineers it
appears that Sun have implemented their posix_spawn
with vfork/execve. At the user level Sun's vfork
is not thread safe (as mentioned quite loudly in their
man page). They do claim however that their posix_spawn
is thread safe (confirmed again via Sun engineers).
So the question after all of that is why does glibc
posix_spawn use fork/execve rather than vfork/execve on
Linux? My reading of vfork on Linux indicates that vfork
is thread safe since it suspends the entire parent (all
threads). Am I wrong.
It would be nice for the Linux (glibc) and Solaris 10
versions of posix_spawn to have the same performance
profile. Is there some danger in using vfork? If there
is can you pass that information on as it currently
appears that we will use 'vfork/execve' under Linux
and 'posix_spawn' under Solaris 10. Our software is
multithreaded and can grow (memory mapped wise) quite
Thanks, I look forward to the answers provided.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. The bug report is informational in nature.
Please file this to http://sources.redhat.com/bugzilla/
instead, this is an enhancement request that should be tracked upstream.
It is impossible to use vfork in the linuxthreads libc, because sigaction
modifies global state, but most probably it should be doable
for NPTL libc, provided a few calls (e.g. *gid) are changed into
inline syscalls and adding code to run atfork registered handlers
before/after vfork in spawni.c.
Thanks for the information. That is exactly what we needed
I will file an enhancement request at the URL you supplied.
If possible it would be great to have Solaris 10 posix_spawn
and NPTL glibc posix_spawn implemented and perform
similarly. Very nice for us since fork/exec can be extremely
This bug item can be closed.
Again much appreciated.
The upstream issue is: