From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org 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 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 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 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 Message-ID: <54099594.2000201@redhat.com> Date: Fri, 05 Sep 2014 10:51:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Eli Zaretskii , Doug Evans CC: ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile 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> In-Reply-To: <83a96ee9lk.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00140.txt.bz2 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