From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8669 invoked by alias); 1 Sep 2014 16:35:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 8650 invoked by uid 89); 1 Sep 2014 16:35:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f47.google.com Received: from mail-yh0-f47.google.com (HELO mail-yh0-f47.google.com) (209.85.213.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 01 Sep 2014 16:34:57 +0000 Received: by mail-yh0-f47.google.com with SMTP id c41so3518138yho.20 for ; Mon, 01 Sep 2014 09:34:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.162.7 with SMTP id x7mr42913677yhk.6.1409589295244; Mon, 01 Sep 2014 09:34:55 -0700 (PDT) Received: by 10.170.66.138 with HTTP; Mon, 1 Sep 2014 09:34:55 -0700 (PDT) In-Reply-To: <20140901124840.GA32201@blade.nx> References: <834mwsh2nu.fsf@gnu.org> <20140901124840.GA32201@blade.nx> Date: Mon, 01 Sep 2014 16:35:00 -0000 Message-ID: Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile From: Doug Evans To: Gary Benson Cc: Eli Zaretskii , "gdb-patches@sourceware.org" , guile-devel Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00025.txt.bz2 On Mon, Sep 1, 2014 at 5:48 AM, Gary Benson wrote: > Doug Evans wrote: >> On Sun, Aug 31, 2014 at 12:36 PM, Eli Zaretskii wrote: >> > > From: Doug Evans >> > > 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.]