This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgomp/52303] New: libgomp leaves threads lying around that cause trouble if the program is later fork()'d
- From: "sdh4 at iastate dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 18 Feb 2012 00:19:34 +0000
- Subject: [Bug libgomp/52303] New: libgomp leaves threads lying around that cause trouble if the program is later fork()'d
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52303
Bug #: 52303
Summary: libgomp leaves threads lying around that cause trouble
if the program is later fork()'d
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: sdh4@iastate.edu
Libgomp creates a thread pool on each thread with a parallel section. This pool
silently hangs around even when no longer in the parallel section.
If the process is later fork()'d and the child process subsequently enters a
parallel section, the child process will deadlock waiting on threads that do
not exist (fork() does not duplicate threads).
The pthreads library provides a mechanism to avoid problems such as this.
Specifically (quoting the manpage for pthread_atfork()):
The pthread_atfork() function provides multi-threaded libraries with a
means to protect themselves from innocent application programs that
call fork(), and it provides multi-threaded application programs with a
standard mechanism for protecting themselves from fork() calls in a
library routine or the application itself.
libgomp should call pthread_atfork() with team.c/gomp_free_thread() (or a
wrapper) as the "prepare" parameter so as to destroy the threadpool before
fork() is executed.
The problem can be worked around by placing the parallel section in a
sub-thread that exits before fork() is called. libgomp automatically destroys
the thread-pool of a thread that exits.