This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Improved ^c support for gdb/guile
- From: Doug Evans <xdje42 at gmail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, guile-devel at gnu dot org
- Date: Mon, 17 Feb 2014 16:37:30 -0800
- Subject: Re: [PATCH v2] Improved ^c support for gdb/guile
- Authentication-results: sourceware.org; auth=none
- References: <wrbvbwejihe dot fsf at sspiff dot org> <wrbr471jxjg dot fsf at sspiff dot org> <834n3x8o7m dot fsf at gnu dot org> <CAP9bCMSE+vNpG2nJNKNQk3QfQHV=cqRdEGmv7T3eEcgQ0cTyFQ at mail dot gmail dot com> <83y519788a dot fsf at gnu dot org>
On Mon, Feb 17, 2014 at 1:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 17 Feb 2014 12:59:22 -0800
>> From: Doug Evans <xdje42@gmail.com>
>> Cc: "gdb-patches@sourceware.org" <gdb-patches@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.