From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11979 invoked by alias); 5 Sep 2014 11:51:42 -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 11879 invoked by uid 89); 5 Sep 2014 11:51:42 -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: mtaout27.012.net.il Received: from mtaout27.012.net.il (HELO mtaout27.012.net.il) (80.179.55.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Sep 2014 11:51:41 +0000 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NBF00B00EM3PL00@mtaout27.012.net.il> for gdb-patches@sourceware.org; Fri, 05 Sep 2014 14:46:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NBF00938FCQDM50@mtaout27.012.net.il>; Fri, 05 Sep 2014 14:46:02 +0300 (IDT) Date: Fri, 05 Sep 2014 11:51:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile In-reply-to: <54099594.2000201@redhat.com> To: Pedro Alves Cc: xdje42@gmail.com, ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <838ulye14l.fsf@gnu.org> 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> X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00143.txt.bz2 > 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 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.