Hi,
Andy Wingo <wi...@pobox.com> skribis:
> 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.
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’.
