> Date: Mon, 31 Aug 2015 22:05:59 -0700 > From: Doug Evans <xdj...@gmail.com> > Cc: Mark Kettenis <mark.kette...@xs4all.nl>, > "gdb-patc...@sourceware.org" <gdb-patc...@sourceware.org>, guile-devel > <guile-devel@gnu.org> > > On Sat, Aug 29, 2015 at 7:37 PM, Eli Zaretskii <e...@gnu.org> wrote: > >> Date: Sat, 29 Aug 2015 23:04:02 +0200 (CEST) > >> From: Mark Kettenis <mark.kette...@xs4all.nl> > >> CC: e...@gnu.org, gdb-patc...@sourceware.org, guile-devel@gnu.org > >> > >> I suppose blocking these in the threads that guile starts is necessary > >> because that is the only way to guarantee that those signals will be > >> delivered to the main gdb thread on POSIX systems. > >> > >> On Windows you probably need to do something completely different. > > > > I might be missing something, because I don't see why. > > The goal here is to block these signals from being sent to the threads > that Guile (or more specifically libgc) creates.
Why only libgc? Don't we want to block these signals in any Guile code invoked later by GDB? > Not sure how to do that on windows. That problem doesn't exist on Windows, but what about Guile application threads launched later?
