From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7855 invoked by alias); 12 Jan 2007 18:31:34 -0000 Received: (qmail 7846 invoked by uid 22791); 12 Jan 2007 18:31:33 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 12 Jan 2007 18:31:27 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H5RBR-00089a-0G; Fri, 12 Jan 2007 13:31:21 -0500 Date: Fri, 12 Jan 2007 18:31:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: async patch (no. 4) Message-ID: <20070112183120.GB30005@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17720.29835.230422.776965@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17720.29835.230422.776965@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) 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-01/txt/msg00318.txt.bz2 On Fri, Oct 20, 2006 at 08:02:35PM +1300, Nick Roberts wrote: Content-Description: message body and .signature > > This is just my latest async patch so time that doesn't get wasted on my > previous one. > > 1) I've moved target specific stuff out of event-loop.c and into linux-nat.c > and used hooks so e.g it should compile (but not work asynchronously) on > Windows. > 2) It now works with poll as well as select. > 3) It's a lot smaller because I've left out changes to gdb-mi.el which > probably aren't of general interest. > 4) The test server-run.exp still fails. I've started looking at this. I suspect I've asked you this before; if so, I apologize. But could you give me the big picture on what is supposed to be different with this patch applied - what's the goal, and should it be the default eventually? No matter how I stare at it, I can't figure out what's going on. A problem I run into often at work is that when you try to merge another person's work, you often don't know how every bit of it works. But in order to review it, you've really got to figure out each line of it. I try to read every line of my patch and ask myself why that line is right / necessary. There's things in this patch that I definitely don't want to merge without understanding them. For instance, the #if 0's in interp_set, and this comment: + /* APPLE LOCAL: I don't think we want to clear the parent interpreter's + The parent interpreter may want to be able to snoop on the child + interpreter through them. */ I thought the interpreters were supposed to be independent, which makes that comment suspicious, and I don't see what it applies to either. Oh, and I noticed that there's nothing here that needs the new argument to deprecated_command_loop_hook. -- Daniel Jacobowitz CodeSourcery