Re: [PATCH v2] Improved ^c support for gdb/guile

[Doug Evans]

On Mon, Feb 17, 2014 at 1:13 PM, Eli Zaretskii <address@hidden> wrote:
>> Date: Mon, 17 Feb 2014 12:59:22 -0800
>> From: Doug Evans <address@hidden>
>> Cc: "address@hidden" <address@hidden>, address@hidden
>>
>> >> +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.