Eli Zaretskii <[email protected]> skribis: >> From: [email protected] (Ludovic Courtès) >> Cc: Eli Zaretskii <[email protected]>, [email protected], >> [email protected] >> Date: Tue, 18 Feb 2014 12:20:39 +0100 >> >> Doug Evans <[email protected]> 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’.
