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

[Doug Evans <xdje42@gmail.com>]

[+ guile-devel]

On Sun, Aug 31, 2014 at 12:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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?

Users are going to want to start threads.
I've seen that already.
I think we should not shy away from them.