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

[Gary Benson <gbenson@redhat.com>]

Doug Evans wrote:
> 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.

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/