From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2866 invoked by alias); 31 Aug 2014 19:36:36 -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 2855 invoked by uid 89); 31 Aug 2014 19:36:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout26.012.net.il Received: from mtaout26.012.net.il (HELO mtaout26.012.net.il) (80.179.55.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 31 Aug 2014 19:36:34 +0000 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NB600K00RNXZ700@mtaout26.012.net.il> for gdb-patches@sourceware.org; Sun, 31 Aug 2014 22:34:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NB600DG1RPS9Y80@mtaout26.012.net.il>; Sun, 31 Aug 2014 22:34:40 +0300 (IDT) Date: Sun, 31 Aug 2014 19:36:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile In-reply-to: To: Doug Evans Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <834mwsh2nu.fsf@gnu.org> References: X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00672.txt.bz2 > 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?