[Top][All Lists]

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

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

From: Ludovic Courtès
Subject: Re: [PATCH v2] Improved ^c support for gdb/guile
Date: Tue, 18 Feb 2014 17:45:27 +0100
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Eli Zaretskii <address@hidden> skribis:

>> From: address@hidden (Ludovic Courtès)
>> Cc: Eli Zaretskii <address@hidden>, address@hidden, address@hidden
>> Date: Tue, 18 Feb 2014 12:20:39 +0100
>> Doug Evans <address@hidden> 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.


reply via email to

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