This is the mail archive of the gcc-patches@gcc.gnu.org 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.

-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

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]