guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Doug Evans
Subject: Re: [PATCH v2] Improved ^c support for gdb/guile
Date: Mon, 17 Feb 2014 12:59:22 -0800

[+ guile-devel]

On Mon, Feb 17, 2014 at 12:43 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Doug Evans <address@hidden>
>> Date: Mon, 17 Feb 2014 15:26:27 -0500
>>
>> Unworkable-as-is optimization trying to avoid queueing asyncs.  Blech.
>>
>> I'm still seeing intermittent testsuite failures because Guile is
>> getting an uncaught SIGINT.
>
> Bother: is this the only way to fix these issues (whatever they are)?
> Because you are quickly getting into non-Windows lands, so there's a
> real risk that the Guile support will not be very useful on Windows
> (except with Cygwin).

The Guile developers are looking into providing a better way to do
this for 2.2 so all is not lost. :-)

>> +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).
For lots of uses of Guile in GDB it's not a total loss.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]