From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5316 invoked by alias); 30 Aug 2006 03:21:15 -0000 Received: (qmail 5308 invoked by uid 22791); 30 Aug 2006 03:21:14 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Aug 2006 03:21:12 +0000 Received: from kahikatea.snap.net.nz (p202-124-124-103.snap.net.nz [202.124.124.103]) by viper.snap.net.nz (Postfix) with ESMTP id 3227C7B84AA; Wed, 30 Aug 2006 15:21:08 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id EF617BE446; Wed, 30 Aug 2006 15:18:59 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17653.930.196634.143646@kahikatea.snap.net.nz> Date: Wed, 30 Aug 2006 03:21:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? In-Reply-To: <20060830023335.GA6377@nevyn.them.org> References: <17652.63229.637451.185345@kahikatea.snap.net.nz> <20060830023335.GA6377@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.50.7 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00232.txt.bz2 Daniel Jacobowitz writes: > On Wed, Aug 30, 2006 at 02:25:01PM +1200, Nick Roberts wrote: > > > > I have recently updated/merged the asynchronous branch (nickrob-async-20060513) > > that I am working on. The overall task is too great for me to complete alone > > and it has attracted no interest as a branch. For these reasons (and the > > coming release of Emacs 22) I would like to merge it with mainline GDB. I have > > tried to arrange that GDB on my branch will only build with the "--async" > > option for GNU/Linux on i386. This should mean that it should build and run as > > before on any other platform, and that itwill only run differently on > > i386-linux-gnu if the "--async" option is specified. > > > > If it passes the current testsuite and I add some new testcases for the > > asynchronous operation (probably in the MI part of the testsuite), may I make > > such a merge? > > Could you remind me what this has to do with the release of emacs 22? In Emacs 22, interaction with gdb is done primarily with annotations (although MI is accessed through "interprter-exec mi" for some features such as variable objects. After Emacs 22, the plan is to switch to MI but this really requires asynchronous behaviour. > I'm not sure what interest you expected to generate on a branch, which > you didn't discuss on any of the mailing lists; as a rule, no one has > time to check out and poke at projects that no one tells them about. I didn't really expect to generate much interest. I thought I had discussed it, although I haven't evangelised as it doesn't seem appropriate. > The last time I heard status from you on the branch, it wasn't working. > I gather it's better off now. That makes it much more interesting. I hadn't committed all the changes I had made until recently, so although it wouldn't have worked, I had thought it would (at least in a limited way). > I think that merging it in without review would be at the least unwise. If people are willing to review it then that is clearly preferable. If not, then after passing the testuite, putting it in the repository would seem to be a good way to test it. If it caused too much disruption then it could be reverted fairy easily and there is plenty of time before the next release. > How big are the changes relative to mainline (diffstat)? A few extra files and a sprinkling of extra lines/if clauses (to test if asynchronous) in twenty or so files. I could run diffstat but I'm not familiar with it. > Is there an > angle from which we can start looking at them? Well, it should be invisible for anything but i386-linux-gnu and work as before on i386-linux-gnu unless "--async" is specified. To that extent it shouldn't interfere with anyone not interested in using it. However, I may used the wrong files to try to achieve this. There is also a file called README.async in the branch. Also it still uses pthreads. You said previously that it should be done in one process and, following a remark from Jim Ingham, that ptrace is non-blocking. AFAICS the problem is that wait *is* blocking and I can't see of a way to deal with that without using another thread. -- Nick http://www.inet.net.nz/~nickrob