> From: Mark H Weaver <m...@netris.org> > Cc: l...@gnu.org, guile-user@gnu.org > Date: Mon, 17 Jun 2013 11:45:51 -0400 > > Eli Zaretskii <e...@gnu.org> 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 +@cindex REPL +@cindex 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
