Re: wip-threads-and-fork

[Ludovic Courtès]

Hi,

Andy Wingo <address@hidden> skribis:

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

[...]

>> 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?)

I agree that ‘primitive-fork’ has a number of important shortcomings.
I’m not convinced that anything needs to be done in the code itself,
though.  It’s just as harmful as ‘pointer->procedure’, in a way.

>>> 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.

Yes, so internal threads could be handled specially.  It seems the
signal thread already gets restarted magically, for instance, thanks to
the various scm_i_ensure_signal_delivery_thread calls.

Thanks,
Ludo’.