Andy Wingo <wi...@pobox.com> writes: > I guess the new thing being the finalizer thread? In theory before the > fork, Guile will stop the finalizer thread. If that's not working, that > could be it. > > Another option would be to disable fork() but only if Guile is built > with threads. Actually this is probably better -- I bet there are Guile > people that expect to be able to fork on Cygwin and would be OK if their > Guile had no threads. > > Please feel free to push to master once there are adequate comments. > Someone will come later and want to enable fork() on Cygwin with threads > and will need to know why it's disabled and what they could do to fix it > :)
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. 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. I’m baking a fix that wipes out user signals before calling “primitve-fork”, and then restores them separately in the parent and child processes. Doing so gives them different mutexes. It required some support in scmsigs.c to: - Have “restore-signals” return a description of the signal handlers, that we can use to restore those handlers. - Have “restore-signals” close the signal pipe (which kills the signal delivery thread). - When closing the signal pipe, wait for the signal delivery thread to exit. 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. All of this is on GNU/Linux, of course, not Cygwin. Derek -- Derek Upham s...@blarg.net