[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile 2.0.9 build on mingw
From: |
Eli Zaretskii |
Subject: |
Re: guile 2.0.9 build on mingw |
Date: |
Tue, 18 Jun 2013 20:17:25 +0300 |
> 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
- Re: guile 2.0.9 build on mingw, (continued)
- Re: guile 2.0.9 build on mingw, Ludovic Courtès, 2013/06/16
- Re: guile 2.0.9 build on mingw, Eli Zaretskii, 2013/06/16
- Re: guile 2.0.9 build on mingw, Eli Zaretskii, 2013/06/12
- Re: guile 2.0.9 build on mingw, Ludovic Courtès, 2013/06/16
- Re: guile 2.0.9 build on mingw, Eli Zaretskii, 2013/06/12
- Re: guile 2.0.9 build on mingw, Ludovic Courtès, 2013/06/16
- Re: guile 2.0.9 build on mingw, Eli Zaretskii, 2013/06/16
- Re: guile 2.0.9 build on mingw, Mark H Weaver, 2013/06/17
- Re: guile 2.0.9 build on mingw,
Eli Zaretskii <=
- Re: guile 2.0.9 build on mingw, Eli Zaretskii, 2013/06/18
- Re: guile 2.0.9 build on mingw, Ludovic Courtès, 2013/06/18
- Re: guile 2.0.9 build on mingw, Eli Zaretskii, 2013/06/18
- Re: guile 2.0.9 build on mingw, Ludovic Courtès, 2013/06/19
- Re: guile 2.0.9 build on mingw, Eli Zaretskii, 2013/06/19