This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Ping x 6: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork

Hi all,

Ping. Again, this patch fixes a limitation in GOMP which makes it
impossible for programmers who care about gcc compatibility to safely
use OpenMP in libraries; GOMP is the last OpenMP implementation with
this limitation.


On Wed, May 14, 2014 at 3:47 PM, Nathaniel Smith <> wrote:
> Hi all,
> Pinging again about the patch below. The lack of this patch is
> essentially a blocker to using gcc+python+openmp together, which is a
> shame, since python is increasingly important in numerical computing,
> openmp is pretty useful, and gcc is the only openmp implementation
> that does not support this functionality.
> -n
> On Tue, Apr 15, 2014 at 1:19 PM, Nathaniel Smith <> wrote:
>> On Tue, Mar 4, 2014 at 11:37 PM, Nathaniel Smith <> wrote:
>>> On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson <> wrote:
>>>> On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
>>>>> Yes, but the problem is that depending on what the user intends to do
>>>>> after forking, our pthread_atfork handler might help or it might hurt,
>>>>> and we don't know which. Consider these two cases:
>>>>>   - fork+exec
>>>>>   - fork+continue to use OMP in child
>>>>> The former case is totally POSIX-legal, even when performed at
>>>>> arbitrary places, even when another thread is, say, in the middle of
>>>>> calling malloc().
>>>> Point well taken.
>>> Hi all,
>>> I guess this patch has gotten all the feedback that it's getting. Any
>>> interest in committing it? :-) I don't have commit access.
>>> 2014-02-12  Nathaniel J. Smith  <>
>>>         * team.c (gomp_free_pool_helper): Move per-thread cleanup to main
>>>         thread.
>>>         (gomp_free_thread): Delegate implementation to...
>>>         (gomp_free_thread_pool): ...this new function. Like old
>>>         gomp_free_thread, but does per-thread cleanup, and has option to
>>>         skip everything that involves interacting with actual threads,
>>>         which is useful when called after fork.
>>>         (gomp_after_fork_callback): New function.
>>>         (gomp_team_start): Register atfork handler, and check for fork on
>>>         entry.
>> Pinging this again now that trunk has re-opened. For compliant code
>> this patch has essentially no impact (OMP-using code acquires a
>> single-line post-fork callback which sets a flag; everything else
>> works the same as now). For technically non-compliant "mostly serial"
>> code that uses OMP in some places, and forks children in other places,
>> it makes a best effort attempt to clean up the thread pool detritus
>> left by a fork, instead of simply deadlocking as currently, so as to
>> allow children to use OMP as well. This makes GOMP match the behaviour
>> of all other OMP implementations I'm aware of.
>> Previous discussion:
>> Bug:
>> I don't have a commit bit -- please commit if acceptable.
>> Cheers,
>> -n
>> --
>> Nathaniel J. Smith
>> Postdoctoral researcher - Informatics - University of Edinburgh
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh

Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh

Attachment: gomp-safe-fork-patch.diff
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]