Bug 131938

Summary: posix_spawn implementation inquiry (why fork/exec rather than vfork/exec).
Product: Red Hat Enterprise Linux 3 Reporter: Dennis <dennis>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED UPSTREAM QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 3.0CC: fedora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-09 04:32:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Dennis 2004-09-07 02:28:33 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):

How reproducible:
Didn't try

Steps to Reproduce:
1. The bug report is informational in nature.

Additional info:
Comment 1 Jakub Jelinek 2004-09-09 03:58:43 EDT
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.
Comment 2 Dennis 2004-09-09 04:20:16 EDT
Thanks for the information. That is exactly what we needed
to know. 

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.

Comment 3 Georg Sauthoff 2017-09-16 02:20:20 EDT
The upstream issue is: