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~