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

[ludo at gnu dot org (Ludovic CourtÃs)]

Doug Evans <xdje42@gmail.com> skribis:

> 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?

I donât remember, Eli: do you have patches pending review for these
issues and other MinGW issues in Guile?

>>> 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

Right, when Guile is built with pthread support, it has a signal
delivery thread.  The actual SIGINT handler (âtake_signalâ in scmsigs.c)
just write one byte to a pipe; the signal delivery thread reads from
that pipe, and queues an async in the destination thread for later
execution.

> 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.

The non-pthread code is used when Guile is built without pthread
support.  In that case, the async is queued directly from the signal
handler.

(I think we should aim to get rid of the signal-delivery thread
eventually, and I remember Mark mentioned it before too.)

HTH,
Ludoâ.