Re: wip-threads-and-fork

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Andy Wingo <wingo@pobox.com> skribis:

> On Sun 26 Feb 2012 23:03, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> skribis:
>>
>>>     +  if (scm_ilength (scm_all_threads ()) != 1)
>>>     +    /* Other threads may be holding on to resources that Guile needs --
>>>     +       it is not safe to permit one thread to fork while others are
>>>     +       running.
>>>     +
>>>     +       In addition, POSIX clearly specifies that if a multi-threaded
>>>     +       program forks, the child must only call functions that are
>>>     +       async-signal-safe.  We can't guarantee that in general.  The best
>>>     +       we can do is to allow forking only very early, before any call to
>>>     +       sigaction spawns the signal-handling thread.  */
>>>     +    SCM_MISC_ERROR ("attempt to fork while multiple threads are running",
>>>     +                    SCM_EOL);
>>
>> Just like fork(2) lets one shoot themself in the foot, I think this is
>> beyond libguile’s scope.  After all, libguile just wraps the OS
>> features, however crippled they may be.
>
> Dunno.  That is certainly the case for things like close-fdes, and the
> FFI.  But if someone really wants an unsafe fork, the FFI can give it to
> them, right?  Keep in mind that portably speaking, you can't even call
> `malloc' in the child, if you forked a program with multiple threads.

How so?

> Primitive-fork is much less necessary now that open-process, the most
> important use case, has been rewritten in C.

That’s right.

Another option would be to expose ‘pthread_atfork’ to Scheme.  It would
allow, for instance, (ice-9 futures) to register a child-side handler to
create a new thread pool, which would sound useful to me.

WDYT?

Thanks,
Ludo’.