From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29723 invoked by alias); 18 Jun 2007 02:46:02 -0000 Received: (qmail 29713 invoked by uid 22791); 18 Jun 2007 02:46:01 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Jun 2007 02:45:59 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 111D5982F9; Mon, 18 Jun 2007 02:45:57 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id C71A1982CE; Mon, 18 Jun 2007 02:45:56 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I07Fr-0003Qx-O9; Sun, 17 Jun 2007 22:46:11 -0400 Date: Mon, 18 Jun 2007 02:46:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: async patch (no. 4) Message-ID: <20070618024611.GA12587@caradoc.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17720.29835.230422.776965@kahikatea.snap.net.nz> <20070112183120.GB30005@nevyn.them.org> <17832.2690.298735.867020@kahikatea.snap.net.nz> <20070112230333.GA7039@nevyn.them.org> <18036.65200.916738.36790@kahikatea.snap.net.nz> <20070617152125.GA17563@caradoc.them.org> <18037.40606.95329.378825@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18037.40606.95329.378825@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes 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 X-SW-Source: 2007-06/txt/msg00320.txt.bz2 On Mon, Jun 18, 2007 at 08:50:38AM +1200, Nick Roberts wrote: > I don't know how you can claim to uderstand almost none of it after you > suggested to me to use SIGCHLD to interrupt the call to select instead of using > threads. I think some of these comments are based on looking at the previous > (eponymous) patch (no. 4). That's the only part of the patch I claim to understand at all. It's not that it's unintelligible - it's that I don't understand why any given line is necessary. Like, what does async_signal_hook do, and why is it called from those particular places? Why does async behavior change where we need to claim the terminal? Are the quit_flag changes still necessary now that we've done some work on QUIT? Why don't the infrun changes break thread handling all over the place? All of these things are the same questions we'd ask for any patch. > This is made harder by the fact that some of the event loop is quite obscure > and I suspect has a level of abstraction that is currently unused. Perhaps a > good starting point would be to simplify this first. Sounds fine to me. We can always re-add it if we want it. -- Daniel Jacobowitz CodeSourcery