Bug 193631 - Is vfork/exec based posix_spawn thread safe?
Summary: Is vfork/exec based posix_spawn thread safe?
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc
Version: 4.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-31 07:07 UTC by Dennis
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-31 07:31:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dennis 2006-05-31 07:07:46 UTC
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.

Dennis.

Comment 1 Jakub Jelinek 2006-05-31 07:31:18 UTC
Why do you think it would not be thread-safe?
Of course it is.

Comment 2 Dennis 2006-05-31 07:50:11 UTC
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
http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/threads/spawn.c)

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.

Dennis.


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