On Tue, Mar 4, 2014 at 11:37 PM, Nathaniel Smith wrote:
> On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson 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
On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson 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 t
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 chil
On Fri, Feb 14, 2014 at 3:43 AM, Jakub Jelinek wrote:
> On Fri, Feb 14, 2014 at 09:21:24AM +0100, Jakub Jelinek wrote:
>> Well, fork is async signal safe function, so calling malloc/free, or any
>> kind of synchronization primitives is completely unsafe there.
>>
>> The only safe thing could be to
On Fri, Feb 14, 2014 at 3:14 PM, Richard Henderson wrote:
> 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.
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
On Fri, Feb 14, 2014 at 09:21:24AM +0100, Jakub Jelinek wrote:
> Well, fork is async signal safe function, so calling malloc/free, or any
> kind of synchronization primitives is completely unsafe there.
>
> The only safe thing could be to atomically or in some global flag (or set
> some TLS flag?)
On Thu, Feb 13, 2014 at 01:22:41PM -0800, Richard Henderson wrote:
> > +/* This is to enable best-effort cleanup after fork. */
> > +static int gomp_we_are_forked = 0;
>
> bool, no explicit initialization, possible removal, see below.
>
> > +static void
> > +gomp_free_thread_pool (int threads_ru
> +/* This is to enable best-effort cleanup after fork. */
> +static int gomp_we_are_forked = 0;
bool, no explicit initialization, possible removal, see below.
> +static void
> +gomp_free_thread_pool (int threads_running)
bool for threads_running. It looks like a count otherwise.
> +gomp_afte
