From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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 14:51:38 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1409917914 9224 80.91.229.3 (5 Sep 2014 11:51:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2014 11:51:54 +0000 (UTC) Cc: xdje42@gmail.com, ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org To: Pedro Alves Original-X-From: gdb-patches-return-115552-gdb-gdb-patches=m.gmane.org@sourceware.org Fri Sep 05 13:51: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 1XPs3N-0003XG-Tr for gdb-gdb-patches@plane.gmane.org; Fri, 05 Sep 2014 13:51:46 +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:date:from:subject:in-reply-to:to:cc:reply-to :message-id:references; q=dns; s=default; b=UFswW14dWP4sc96JVHt7 ilydJriDSAS/MfAXHHh5u5jxm7lFVM/JZg3rR5epM6/XbJiZZ9Zn6KApniNMDmEQ eA/cAwSRcPW6ED7DrlWtQxhE1iVORU0PxccJDKqsdQnXciYFh3GWEgkalx/aSxXS gxhfSc5CCoxOQnmynWxL02k= 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:date:from:subject:in-reply-to:to:cc:reply-to :message-id:references; s=default; bh=MaRZnHGifacUoa6TN7sSoJ5Yrf g=; b=yzFhVzEtxy/QpZuoiRj3VAvTKnE4bDFjb90Oj6WtMuMGhhdDhf1tNIXLjj o9M74UYDptB5jYUVL1Xd0wN9EckC1gJr/L2IUcKs/CFLE0u14TiJ6lK9mygC+NBc QYfOU6MUKgwE0tbGKPg8u+p01Mk3hxg1IWLSRShPM3taNSjGg= Original-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-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: gdb-patches-owner@sourceware.org Original-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 Original-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 Original-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) Original-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) In-reply-to: <54099594.2000201@redhat.com> X-IsSubscribed: yes Xref: news.gmane.org gmane.comp.gdb.patches:100530 gmane.lisp.guile.devel:17415 Archived-At: > 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.