On Sun 26 Feb 2012 23:03, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo <wi...@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.
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/
