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

[Nathaniel Smith <njs at pobox dot com>]

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.

-n

On Wed, May 14, 2014 at 3:47 PM, Nathaniel Smith <njs@pobox.com> 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 <njs@pobox.com> wrote:
>> On Tue, Mar 4, 2014 at 11:37 PM, Nathaniel Smith <njs@pobox.com> wrote:
>>> On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson <rth@redhat.com> 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  <njs@pobox.com>
>>>
>>>         * 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:
>>   http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00813.html
>> Bug:
>>    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035
>>
>> I don't have a commit bit -- please commit if acceptable.
>>
>> Cheers,
>> -n
>>
>> --
>> Nathaniel J. Smith
>> Postdoctoral researcher - Informatics - University of Edinburgh
>> http://vorpus.org
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org



-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

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