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? Thanks, Gary -- http://gbenson.net/
