This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]