From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19049 invoked by alias); 1 Sep 2014 12:48:49 -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 19024 invoked by uid 89); 1 Sep 2014 12:48:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 01 Sep 2014 12:48:47 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s81Cmg2i019149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 1 Sep 2014 08:48:43 -0400 Received: from blade.nx (ovpn-116-113.ams2.redhat.com [10.36.116.113]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s81CmfWt016342; Mon, 1 Sep 2014 08:48:42 -0400 Received: by blade.nx (Postfix, from userid 1000) id 003BA2640D7; Mon, 1 Sep 2014 13:48:40 +0100 (BST) Date: Mon, 01 Sep 2014 12:48:00 -0000 From: Gary Benson To: Doug Evans Cc: Eli Zaretskii , "gdb-patches@sourceware.org" , guile-devel Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile Message-ID: <20140901124840.GA32201@blade.nx> References: <834mwsh2nu.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00014.txt.bz2 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? Thanks, Gary -- http://gbenson.net/