On Mon, Feb 17, 2014 at 1:13 PM, Eli Zaretskii <e...@gnu.org> wrote:
>> Date: Mon, 17 Feb 2014 12:59:22 -0800
>> From: Doug Evans <xdj...@gmail.com>
>> Cc: "gdb-patc...@sourceware.org" <gdb-patc...@sourceware.org>,
>> guile-devel@gnu.org
>>
>> >> +void
>> >> +gdbscm_initialize_sigint (void)
>> >> +{
>> >> + siscm_sigint_pipe[0] = siscm_sigint_pipe[1] = -1;
>> >> +
>> >> + if (!SCM_USE_PTHREAD_THREADS)
>> >> + {
>> >> + warning (_("Guile does not have pthreads support."));
>> >> + warning (_("Proper SIGINT handling for Guile will be
>> >> unavailable."));
>> >> + return;
>> >> + }
>> >
>> > The above is what worries me. Guile currently doesn't work in the
>> > native MinGW build if configured with threads (it crashes, hangs,
>> > etc.). Can't we have decent SIGINT handling without pthreads?
>>
>> With 2.0.x, no.
>> I'm ok with changing the warning, e.g., not printing it at all on
>> systems where it would otherwise always be printed, and instead
>> documenting the issue for such systems.
>>
>> The downside is that while Scheme code is running SIGINT is ignored
>> (unless one is in the repl, or sets up a SIGINT handler oneself).
>
> Ignored why? because GDB sets the handler to SIG_IGN? Or for some
> other reason?
A better way to phrase that is the SIGINT is deferred until the call
out to Guile returns.
Why? Because Guile's SIGINT handling in 2.0.x requires a separate
thread: that's how all async signals are handled in Guile.
ref: guile-2.0.9/libguile/scmsigs.c
I'll let guile-devel take over at this point - I understand the code,
but may miss something noteworthy.
There is code in scmsigs.c to handle the non-pthread case but it's not
clear how much is exported nor how well it works.
