This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 31 Aug 2014 22:36:37 +0300
- Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
- Authentication-results: sourceware.org; auth=none
- References: <m31trwv5o1 dot fsf at sspiff dot org>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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?