[+ guile-devel] 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.
