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 5: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork

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.


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

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]