---- Andy Wingo <[EMAIL PROTECTED]> wrote: >It seems fork + signal handling is borked with a guile compiled --with-threads >-- and that's not >specific to the vm branch.
And this is the very reason that Debian guile was built --without-threads. It's just not a good idea to mix fork() with pthreads. The main issue is that the child process has all the state of the parent, including the locked state of all the mutexes. However, the threads that hold them no longer exist, so deadlocks are almost inevitable. There is a pthread_atfork() call that should allow you to make things safe before a fork() and restore them properly afterwards. Guile *might* be able to use this to handle all the mutexes that it creates an knows about, but what the ones a user creates in their C code, or what some C library does? Now, this is not much of a problem with fork()+exec(). The problem is mixing "fork threading" (where you keep the same process image in the child) and posix threads. -Dale
