Re: wip-threads-and-fork

[Andy Wingo]

Hi :)

On Wed 21 Mar 2012 22:26, address@hidden (Ludovic Courtès) writes:

> Without exposing ‘pthread_atfork’, how would you suggest making user
> code “fork-safe”?  A use case would be reviving the futures thread pool
> after ‘fork’.

Humm, just tried to think about it for 10 minutes or so and I'm not
coming up with anything.  I don't think it's possible...

>> I came to the opinion, having run a threaded, forking program, that we
>> would be much better off if we provided good abstractions to spawn
>> processes, but that expecting fork() to work in a multithreaded program
>> is not realistic.
>
> Yes, things like ‘open-process’ make sense.
>
> What about adding a big fat warning in the doc about use of
> ‘primitive-fork’ in a multi-threaded program?

Sure.  WDYT about a warning at runtime as well?  (I assume you still
don't like the current master behavior of throwing an exception if other
threads are running?)

>> Still, there is one other thing that perhaps we could do to shut down
>> the signal handling thread around a fork().  Dunno, perhaps it is worth
>> looking into.
>
> What would be the expected benefit?

Let's assume a knowledgable user writing a program.  The user goes to
call primitive-fork, and thinks, "Am I using threads in this program?
Because if I am, it's not safe for me to fork."  The user looks and sees
that up to that point, no threads are used, so the user goes ahead.

If Guile started any threads on the user's behalf, this would invalidate
this user's mental calculation.

Currently in master, we stop the finalizer thread from within
primitive-fork, leaving the next finalizer run to spawn it again.

We could do something similar with the signal thread.

The alternative is to document "don't fork after calling sigaction".

Regards,

Andy
-- 
http://wingolog.org/