From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21738 invoked by alias); 31 Aug 2014 20:20:52 -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 21718 invoked by uid 89); 31 Aug 2014 20:20:51 -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-f41.google.com Received: from mail-yh0-f41.google.com (HELO mail-yh0-f41.google.com) (209.85.213.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 31 Aug 2014 20:20:50 +0000 Received: by mail-yh0-f41.google.com with SMTP id 29so2921108yhl.0 for ; Sun, 31 Aug 2014 13:20:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.129.205 with SMTP id h53mr37508217yhi.74.1409516448193; Sun, 31 Aug 2014 13:20:48 -0700 (PDT) Received: by 10.170.66.138 with HTTP; Sun, 31 Aug 2014 13:20:48 -0700 (PDT) In-Reply-To: <834mwsh2nu.fsf@gnu.org> References: <834mwsh2nu.fsf@gnu.org> Date: Sun, 31 Aug 2014 20:20:00 -0000 Message-ID: Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile From: Doug Evans To: Eli Zaretskii Cc: "gdb-patches@sourceware.org" , guile-devel Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00673.txt.bz2 [+ guile-devel] 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.