Bug 193631 - Is vfork/exec based posix_spawn thread safe?
Is vfork/exec based posix_spawn thread safe?
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-05-31 03:07 EDT by Dennis
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-31 03:31:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dennis 2006-05-31 03:07:46 EDT
This is more of an information retrieval item rather than a bug report.

We are contemplating replacing our process launching code which is based around
fork/exec with posix_spawn (using the POSIX_SPAWN_USEVFORK flag).

We plan to do that for both our Linux and Solaris 10 ports of our Database Server.

Under Solaris 10 posix_spawn is based around vfork/exec. Sun has implemented
their vfork/exec based posix_spawn in a thread safe fashion.

Question, is POSIX_SPAWN_USEVFORK based posix_spawn thread safe under Linux?
Is vfork/exec thread safe under Linux?

Very little documentation exists indicating glibc vfork thread-safety.

Any information that can be provided one way or the way would be much appreciated.

Comment 1 Jakub Jelinek 2006-05-31 03:31:18 EDT
Why do you think it would not be thread-safe?
Of course it is.
Comment 2 Dennis 2006-05-31 03:50:11 EDT
Thanks Jacub, that was a quick response.

The reasons we had concerns relates to two bits of Solaris information.

Firstly the Solaris vfork man page which states

> In a multithreaded application,  vfork()  borrows  only  the
> thread  of  control  that called vfork() in the parent; that
> is, the child contains only one thread. The use  of  vfork()
> in  multithreaded  applications,  however,  is unsafe due to
> race conditons that can cause the child  process  to  become
> deadlocked  and consequently block both the child and parent
> process from execution indefinitely.

The second bit of information comes from the Open Solaris
posix_spawn implementation (from

Which states

 * For MT safety, do not invoke the dynamic linker after calling vfork().
 * If some other thread was in the dynamic linker when this thread's parent
 * called vfork() then the dynamic linker's lock would still be held here
 * (with a defunct owner) and we would deadlock ourself if we invoked it.
 * Therefore, all of the functions we call here after returning from
 * _vfork() in the child are not and must never be exported from libc
 * as global symbols.  To do so would risk invoking the dynamic linker.

Yes, Linux and Solaris are completely different. We were just wanting
some confirmation one way or the other. Sun is adament that vfork is
thread unsafe, however their vfork based posix_spawn is thread safe.

On the Linux it has been difficult to find definitive thread-safety
confirmation for vfork and vfork based posix_spawn.


Note You need to log in before you can comment on or make changes to this bug.