[PATCH v2] Improved ^c support for gdb/guile
Ludovic Courtès
ludo@gnu.org
Tue Feb 18 16:45:00 GMT 2014
Eli Zaretskii <eliz@gnu.org> skribis:
>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org, guile-devel@gnu.org
>> Date: Tue, 18 Feb 2014 12:20:39 +0100
>>
>> Doug Evans <xdje42@gmail.com> skribis:
>>
>> I don’t remember, Eli: do you have patches pending review for these
>> issues and other MinGW issues in Guile?
>
> I don't know, you tell me. I sent several changesets in June,
> in these messages:
OK, will follow-up on guile-devel.
>> 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.
>
> So why cannot this code be used by GDB?
Because GDB uses whichever Guile is available. If the user has Guile
built with pthread support, then that’s what GDB uses.
>> (I think we should aim to get rid of the signal-delivery thread
>> eventually, and I remember Mark mentioned it before too.)
>
> Right, which raises again the question why use in GDB something that
> is slated for deletion.
I think there’s a misunderstanding. Doug’s signal-delivery thread will
work no matter what strategy Guile uses internally. My comment above
was referring to Guile’s internal implementation of signal delivery,
which does not affect what GDB does.
> Btw, where does the value of SCM_USE_PTHREAD_THREADS come from? Is it
> something defined by the installed Guile headers?
Yes, and determined at Guile configure time.
Ludo’.
More information about the Gdb-patches
mailing list