Bug 131938
| Summary: | posix_spawn implementation inquiry (why fork/exec rather than vfork/exec). | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Dennis <dennis> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED UPSTREAM | QA Contact: | Brian Brock <bbrock> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | fedora |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-09 08:32:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 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 slow. This bug item can be closed. Again much appreciated. Dennis. The upstream issue is: https://sourceware.org/bugzilla/show_bug.cgi?id=378 |
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 problem. 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 large. Thanks, I look forward to the answers provided. Dennis. Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: 1. The bug report is informational in nature. 2. 3. Additional info: