On Mon, Sep 1, 2014 at 5:48 AM, Gary Benson <gben...@redhat.com> wrote: > Doug Evans wrote: >> On Sun, Aug 31, 2014 at 12:36 PM, Eli Zaretskii <e...@gnu.org> wrote: >> > > From: Doug Evans <xdj...@gmail.com> >> > > Date: Sun, 31 Aug 2014 12:07:58 -0700 >> > > >> > > Basically, current Guile (git) starts an internal thread (the >> > > "finalizer" thread), and libgc as of 7.4 now starts several >> > > marker threads by default (before 7.4.0 one needed to configure >> > > libgc with --enable-parallel-mark). >> > > >> > > When other threads are running, and they haven't blocked >> > > SIGCHLD, then the kernel may send SIGCHLD to these threads, >> > > leaving gdb hung in the sigsuspend calls in linux-nat.c. >> > >> > A heretic thought: is it at all a good idea to have Guile (and GC) >> > start threads when they run under GDB? GDB is a single-threaded >> > program, so having it linked against libraries that start threads >> > whenever they like is IME a source of subtle problems (like this >> > one) and a lot of pain down the road. Anything GDB does that >> > affects the global environment of the whole program (e.g., I/O >> > redirection) will also affect those threads, with who knows what >> > consequences. >> > >> > So maybe The Right Way of fixing these problems is configure Guile >> > and GC so that they never start any additional threads? >> >> Users are going to want to start threads. >> I've seen that already. >> I think we should not shy away from them. > > This patch ensures the internal threads are created with SIGCHLD > blocked. Does something do this for other (user started?) threads?
What to do for user-started threads is an open question, both for Python and Guile. For reference sake, see PR 17314. [Still working on a testcase. What I added to the PR is just a snippet to get thoughts down.]
