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: unassig...@gcc.gnu.org
ReportedBy: s...@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.
