Eli Zaretskii <e...@gnu.org> skribis: >> From: l...@gnu.org (Ludovic Courtès) >> Cc: Eli Zaretskii <e...@gnu.org>, gdb-patc...@sourceware.org, >> guile-devel@gnu.org >> Date: Tue, 18 Feb 2014 12:20:39 +0100 >> >> Doug Evans <xdj...@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’.
