Re: Cygwin port of Guile 2.2

[Andy Wingo]

On Fri 14 Apr 2017 15:41, Derek Upham <address@hidden> 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