[Bug libgomp/52303] New: libgomp leaves threads lying around that cause trouble if the program is later fork()'d

["sdh4 at iastate dot edu" <gcc-bugzilla@gcc.gnu.org>]

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.