This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
- From: Doug Evans <xdje42 at gmail dot com>
- To: Gary Benson <gbenson at redhat dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, guile-devel <guile-devel at gnu dot org>
- Date: Mon, 1 Sep 2014 09:34:55 -0700
- 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> <834mwsh2nu dot fsf at gnu dot org> <CAP9bCMTNsoi6AhQxJtzjc6=o9iHi8TXkX32OiKbArAuAnsjZUQ at mail dot gmail dot com> <20140901124840 dot GA32201 at blade dot nx>
On Mon, Sep 1, 2014 at 5:48 AM, Gary Benson <email@example.com> wrote:
> Doug Evans wrote:
>> On Sun, Aug 31, 2014 at 12:36 PM, Eli Zaretskii <firstname.lastname@example.org> wrote:
>> > > From: Doug Evans <email@example.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?
What to do for user-started threads is an open question, both for
Python and Guile.
For reference sake, see PR 17314.
[Still working on a testcase. What I added to the PR is just a
snippet to get thoughts down.]