Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: address@hidden (Ludovic Courtès)
> Cc: address@hidden
> Date: Sun, 09 Jun 2013 22:33:50 +0200
> 
> Eli Zaretskii <address@hidden> 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.