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~

Reply via email to