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 11:51:00 +0100 Message-ID: <54099594.2000201@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> 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 1409914288 29572 80.91.229.3 (5 Sep 2014 10:51:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2014 10:51:28 +0000 (UTC) Cc: ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org To: Eli Zaretskii , Doug Evans Original-X-From: gdb-patches-return-115549-gdb-gdb-patches=m.gmane.org@sourceware.org Fri Sep 05 12:51:23 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 1XPr6s-0003Bw-Ax for gdb-gdb-patches@plane.gmane.org; Fri, 05 Sep 2014 12:51:18 +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=Tzl+yyCcwhyalCW+ enc8CZNKwhgucIvk5nF72pnMNysjz1FvIeE/lq6V2y2XzEyXbi+BkHXgiORzqEEm Vo6mtck6TJp7Ql/gXHSHSzYDbxh6QoswPI/v6k4hAaoV5BzjXCvSZb6jHa74TPDU 8V0kqqZ6K9883r4Ii2APPmOvY4s= 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=mMQHKPYaciil8+yR4HjRUJ a/aUs=; b=FPNvvBpOSEjUuo+woChbxViw48Dd10ZjYw3o3l25owU5sh/Jx0VLpK LHTh3CZqCneAg9WwVqZSoE15LwO2fJBgdX+cYQz5z6pkTdag4E0IVibuSm3jGk1U rYJkQHyYzhLajB6UZikxY1Cw5x4nNtoiDg6cRQb4Wc/oB9AO9bhrc= Original-Received: (qmail 4122 invoked by alias); 5 Sep 2014 10:51:14 -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 4109 invoked by uid 89); 5 Sep 2014 10:51:13 -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 10:51:12 +0000 Original-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 s85Ap26O027667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Sep 2014 06:51:06 -0400 Original-Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s85Ap0rM011027; Fri, 5 Sep 2014 06:51:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 In-Reply-To: <83a96ee9lk.fsf@gnu.org> Xref: news.gmane.org gmane.comp.gdb.patches:100527 gmane.lisp.guile.devel:17413 Archived-At: On 09/05/2014 09:48 AM, Eli Zaretskii wrote: >> From: Doug Evans >> Cc: ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org >> Date: Fri, 05 Sep 2014 01:26:28 -0700 >> >> we can't physically prevent [users] from starting threads. > > Of course we can: if Guile gives us a way to disable threads, any user > extension that attempts to start a thread will simply fail. > >> We pretty much leave them that way already given the myriad >> of things they can do to mess up gdb without threads. > > ?? The rest of GDB is compiled C code which users cannot change > without recompiling. And it's a single-threaded code. And it's under > our close scrutiny. So I see no problems here. > >> The python side of things is too silent on whether threads are supported >> there. >> https://sourceware.org/gdb/current/onlinedocs/gdb/Basic-Python.html#Basic-Python I'd be strongly against preventing extensions from using threads. As an example, tromey's wip/prototype gdb frontend written as a python extension to gdb uses threads: https://gitorious.org/gdb-gui Even GDB itself isn't really strictly single-threaded -- e.g., on Windows, we spawn threads to handle I/O: ser-mingw.c: state->thread = CreateThread (NULL, 0, thread_fn, scb, 0, &threadId); 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. Thanks, Pedro Alves