From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pedro Alves Newsgroups: gmane.comp.gdb.patches,gmane.lisp.guile.devel Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile Date: Fri, 05 Sep 2014 13:48:25 +0100 Message-ID: <5409B119.1090606@redhat.com> References: <834mwsh2nu.fsf@gnu.org> <8338ccgj78.fsf@gnu.org> <87ppffabw8.fsf@gnu.org> <83y4u3flr2.fsf@gnu.org> <87r3zv71qy.fsf@gnu.org> <83vbp7fer3.fsf@gnu.org> <83iol6f3iy.fsf@gnu.org> <83a96ee9lk.fsf@gnu.org> <54099594.2000201@redhat.com> <838ulye14l.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1409921333 20671 80.91.229.3 (5 Sep 2014 12:48:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2014 12:48:53 +0000 (UTC) Cc: xdje42@gmail.com, ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org To: Eli Zaretskii Original-X-From: gdb-patches-return-115553-gdb-gdb-patches=m.gmane.org@sourceware.org Fri Sep 05 14:48:47 2014 Return-path: Envelope-to: gdb-gdb-patches@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPswV-0002kf-5i for gdb-gdb-patches@plane.gmane.org; Fri, 05 Sep 2014 14:48:43 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=WVRDxTeqCyxLr3rD FKxxjo3ecTKgi/KevEJUjdEcuc3zZ4J7lOBJ4EmLrMZvtjqamGs/rDAzBJCtpP2M LZF1ID1FV4R983Z1xqWT9mBbb7fUns9NqolrVWsNysiuQ4JltRaLUX8MHEp1WJij a/IqxMmrDIYw8mey7cjBTArsxSo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=default; bh=pHrjJWWAC7VrGwRLzguKfD RNyE8=; b=VtoZb+jFWvwUzluqGbeM+HIwC33JzaBztHjOxRuj4pG49gOBnxaBEl H0i4Jf/T8TUa9yZ5LIjHhT6EHZBshixYEVt9en/MLqi3zOlC5ji4M+4x1+YoRfvW WqAcurJlIHT288vrizEa6f76owyF3h2Gks0HhChk3gnYF4JhFy39I= Original-Received: (qmail 14991 invoked by alias); 5 Sep 2014 12:48:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: gdb-patches-owner@sourceware.org Original-Received: (qmail 14969 invoked by uid 89); 5 Sep 2014 12:48:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Original-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; Fri, 05 Sep 2014 12:48:33 +0000 Original-Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s85CmSK7004478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Sep 2014 08:48:28 -0400 Original-Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s85CmPc4005780; Fri, 5 Sep 2014 08:48:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 In-Reply-To: <838ulye14l.fsf@gnu.org> Xref: news.gmane.org gmane.comp.gdb.patches:100531 gmane.lisp.guile.devel:17417 Archived-At: On 09/05/2014 12:51 PM, Eli Zaretskii wrote: >> Date: Fri, 05 Sep 2014 11:51:00 +0100 >> From: Pedro Alves >> CC: ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org >> >> I'd be strongly against preventing extensions from using threads. > > Then how do you propose to deal with the difficulties I listed in one > of my previous messages? As you said, both Guile and Python support loading foreign libraries, so those difficulties aren't really specific to multi-threading. Even without loading foreign libraries, it seems to me that a single-threaded extension script can just as well mess up gdb, but doing some of the things you list, like e.g., messing with signal handlers and timers. So I think we should say that you mustn't change global environment behind gdb's feet, and if you do so, you're in undefined territory. I thikn we also need to make clear that you can _only_ interact with GDB through the main thread. You can't have a random thread call into GDB's APIs, as there's no locking. > >> As an example, tromey's wip/prototype gdb frontend written as a >> python extension to gdb uses threads: > > You don't need to convince me that forbidding threads takes away some > significant functionality. This is a question of finding the right > balance, not whether threads are useful. > >> Even GDB itself isn't really strictly single-threaded -- e.g., on >> Windows, we spawn threads to handle I/O: > > That just means we already take some risk, where no other solution was > possible, or reasonably practical. It does not mean we should from > now on be casual about adding more of that. Moreover, this is _us_ > doing threads, not users on whose code we have no control. > >> Just last night I was debugging something in non-stop mode >> where a ton of events happen behind the scenes without causing >> a user-visible stop (a bunch of parallel single-steps), and >> noticing how the cli/prompt becomes so unresponsive, because the event >> loop handles either target events or input events in sequence, not >> in parallel, and thinking that probably to completely fix this we'd >> need to move stdin/readline handling to a separate thread. > > It's fine with me to redesign GDB to be a multi-threaded program. But > you know better than I do how deeply single-threaded is the current > GDB design. I'm talking about allowing threads with arbitrary code > into our back-door, while GDB currently doesn't and cannot handle that > very well. Ack. Thanks, Pedro Alves