This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork
- From: Richard Henderson <rth at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Nathaniel Smith <njs at pobox dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Feb 2014 12:14:16 -0800
- Subject: Re: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork
- Authentication-results: sourceware.org; auth=none
- References: <CAPJVwBkOF5GnrMr=4d1ehEKRGkY0tHzJzfXAYBguawu9y5wxXw at mail dot gmail dot com> <52FD37A1 dot 6040404 at redhat dot com> <20140214082124 dot GA20378 at tucnak dot redhat dot com>
On 02/14/2014 12:21 AM, Jakub Jelinek wrote:
>> Any reason not to just run gomp_free_thread_pool from gomp_after_fork_callback
>> directly? I see no restrictions on what kind of code is allowed to execute
>> during that callback.
>
> Well, fork is async signal safe function, so calling malloc/free, or any
> kind of synchronization primitives is completely unsafe there.
That's as may be, but even the opengroup's rationale for pthread_atfork
mentions using locks in the three callbacks. I strongly suspect that no real
use of pthread_atfork can ever really be async safe.
r~