Bug 193631

Summary:	Is vfork/exec based posix_spawn thread safe?
Product:	Red Hat Enterprise Linux 4	Reporter:	Dennis <dennis>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.0
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:	2006-05-31 07:31:18 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:

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.