> From: l...@gnu.org (Ludovic Courtès) > Cc: guile-user@gnu.org > Date: Sun, 09 Jun 2013 22:33:50 +0200 > > Eli Zaretskii <e...@gnu.org> skribis: > > > There's only one thread at this point, its backtrace is below. > > Actually, I don't see more than this one thread during the entire run > > (GDB doesn't announce any thread birth or death, and Process Explorer > > shows a single thread in the process at all times). Note that we are > > talking about a child guile process -- it's that one that prints the > > weird traceback and hangs. The parent just waits for the child to > > finish. > > Where’s the child process created exactly? It’s not clear to me.
Sorry, this was a red herring. The parent process is the guile.exe from libguile, which is just a wrapper around the real guile.exe, which is hidden in its .libs subdirectory. So the parent is not important; only the child is. > Anyway, it could be that the parent Guile process has more than one > thread, and the child Guile process (which has only one thread) ends up > with some mutexes locked, and possibly inconsistent state. See above: the parent is not really Guile, it's just called guile.exe to dupe all kinds of scripts (and me ;-). > Normally a Guile with multiple threads warns upon ‘fork’, precisely > because of this problem (see ‘scm_fork’ in posix.c.) As I wrote earlier, there's no 'fork' in MinGW, so I'm not sure this is at all relevant. Or maybe it is -- perhaps the threads infrastructure in Guile really assumes Posix functionality that just isn't there in the MinGW build? > However, that warning doesn’t take into account the signal thread, nor > the GC thread (if any). So, although that seems unlikely, there could > still be issues, for instance if the ‘scm_fork’ call happens while > ‘signal_delivery_thread_mutex’ is locked. What signal would that be? Are you sure it exists, or is emulated, on Windows? Thanks.
