Hi, Andy Wingo <wi...@pobox.com> skribis:
> On Wed 21 Mar 2012 22:26, l...@gnu.org (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’.
