Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile

[Eli Zaretskii <eliz@gnu.org>]

> From: Doug Evans <xdje42@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?