Re: wip-threads-and-fork

[Andy Wingo]

On Sun 26 Feb 2012 23:03, address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> 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.

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

Finally, I think it's particularly important to constrain primitive-fork
because it prevents composition of various modules.  If I have a module
that uses futures, and a module that forks, I can't compose them.

Andy
-- 
http://wingolog.org/