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

[ludo@gnu.org (Ludovic Courtès)]

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