Re: guile 2.0.9 build on mingw

[Eli Zaretskii]

> From: Mark H Weaver <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Mon, 17 Jun 2013 11:45:51 -0400
> 
> Eli Zaretskii <address@hidden> writes:
> > The bug report at http://bugs.gnu.org/14171 says that when Guile is
> > compiled with enable-posix, it "can't start the REPL".  Can someone
> > please show me a simple way of trying that?
> 
> Just run Guile in such a way that would lead to an interactive Guile
> prompt, e.g. by running without any command-line arguments.

Ah, so REPL means "read-eval-print loop".  It's a bit bizarre to see
this acronym used and explained in the Guile reference manual, but
not indexed, so please consider the trivial 2-line patch below.

> Two people
> reported that when built with --enable-posix, Guile would work when run
> in a non-interactive way (e.g. using -c or running a script), but would
> hang when run interactively.
> 
> As described in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14171#14>,
> the problem seems to be in 'call-with-sigint' defined in
> ice-9/top-repl.scm.  Note that 'call-with-sigint' only installs a signal
> handler if POSIX support is enabled, and otherwise is a no-op.
> --disable-posix avoided the hang and allowed the REPL to be reached.

I looked into this.  First of all, the Guile I built without threads,
but with --enable-posix does not hang when I invoke it without
arguments.  It shows me the prompt and allows me to type commands.  It
also reacts correctly to Ctrl-C.  So the fact is that POSIX does not
by itself do any harm in the MinGW build.

My analysis of this, which included both reading the relevant sources
and the above-mentioned bug report, is that the conclusion in that bug
report is based on a mistaken interpretation of the reasons for the
hang.  It is not related to HAVE_POSIX, except accidentally.  It's
true that call-with-sigint installs a signal handler (by eventually
calling scm_sigaction_for_thread) only if HAVE_POSIX is defined.
However, nothing in the code of scm_sigaction_for_thread has anything
to do with HAVE_POSIX.  By contrast, it has _everything_ to do with
threads: it calls the same scm_i_ensure_signal_delivery_thread,
which unsurprisingly is the same place where I found Guile to hang
even in batch mode.  When SCM_USE_PTHREAD_THREADS is not defined,
scm_i_ensure_signal_delivery_thread is a no-op.

Moreover, the backtrace in the bug report clearly shows that Guile
hangs in pthread-related functions called from
scm_sigaction_for_thread, not in something that is only included if
HAVE_POSIX is defined.  So I concluded that disabling POSIX just works
around that problem, by not installing the signal handler, which
avoids calling scm_i_ensure_signal_delivery_thread, but the problem
itself, with threads usage, is still there.

IOW, it's not the POSIX functionality that is the culprit; it's
threads.

Which reminds me that it would be nice if someone could comment on the
findings and questions I published in
http://lists.gnu.org/archive/html/guile-user/2013-06/msg00030.html.

Here's the patch for the manual:

  Improve indexing of "REPL".

        * doc/ref/scheme-using.texi (Using Guile Interactively): Add index
        entries for REPL.

diff --git a/doc/ref/scheme-using.texi b/doc/ref/scheme-using.texi
index 4422c18..350df9c 100644
--- a/doc/ref/scheme-using.texi
+++ b/doc/ref/scheme-using.texi
@@ -24,6 +24,8 @@ $3 = b
 @end lisp
 
 @noindent
address@hidden REPL
address@hidden read-eval-print loop
 This mode of use is called a @dfn{REPL}, which is short for
 ``Read-Eval-Print Loop'', because the Guile interpreter first reads the
 expression that you have typed, then evaluates it, and then prints the