On Fri 14 Apr 2017 15:41, Derek Upham <s...@blarg.net> writes: > There’s the finalizer thread, but there’s also the signal delivery > thread. The “sigaction” code ensures that signal delivery thread is > running. And note that “primitive-fork” is supposed to display a > warning if you are forking with outstanding threads, but it explicitly > ignores the signal delivery thread during its check.
Yep, though the signal delivery thread doesn't run unless you have installed a signal handler. I think currently the combination of signals + guile-with-threads + primitive-fork (rather than open-process) isn't supported. It warns in 2.2 but the situation was the same in 2.0. I am not sure how it can be made to work (though I did try!) and would be interested to see your fix :) > I have found that what actually hangs after a fork are the mutexes > supporting the threads: they are kernel-level resources, referenced by > ID, and end up being shared between parent and child. Which ones, precisely? > I don’t think there’s any safe way to restore the finalizer thread and > support SCSH-style (begin ...) process forms. Shutting down the > finalizer thread is the best we can do. The finalizer thread should be restored as needed, the next time GC calls notify_finalizers_to_run. I think also that if you are most interested in a system in which primitive-fork plays a large role, then probably you want a Guile without threads (including the GC mark threads). Threads + fork is not a recipe for success :) Andy
