[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cygwin port of Guile 2.2
From: |
Andy Wingo |
Subject: |
Re: Cygwin port of Guile 2.2 |
Date: |
Mon, 17 Apr 2017 10:04:42 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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