From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18370 invoked by alias); 26 Sep 2006 22:24:12 -0000 Received: (qmail 18362 invoked by uid 22791); 26 Sep 2006 22:24:11 -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; Tue, 26 Sep 2006 22:24:08 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GSLLS-0007xa-Kj; Tue, 26 Sep 2006 18:24:06 -0400 Date: Tue, 26 Sep 2006 22:24:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? Message-ID: <20060926222406.GA30535@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb@sources.redhat.com References: <17652.63229.637451.185345@kahikatea.snap.net.nz> <20060830023335.GA6377@nevyn.them.org> <17653.930.196634.143646@kahikatea.snap.net.nz> <20060830040113.GA8257@nevyn.them.org> <17654.994.815362.897653@kahikatea.snap.net.nz> <20060830214257.GA5397@nevyn.them.org> <17688.59135.24869.397517@kahikatea.snap.net.nz> <20060926123757.GA9879@nevyn.them.org> <17689.42274.369631.215081@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17689.42274.369631.215081@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) 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-09/txt/msg00157.txt.bz2 On Wed, Sep 27, 2006 at 10:09:38AM +1200, Nick Roberts wrote: > > Yes, this should work, though it seems cumbersome. When you've got > > a single thread, you don't need to pass actual data around an fd, > > just a marker "yes i'm ready now". > > I don't quite follow, that's how the event loop works. Even user input > requires an fd through stdin_event_handler. There is a provision for other > events but currently only file events are used. Right - but you don't need to put the actual data (e.g. the PID and status) through the fd. I guess it doesn't hurt, but it does make things harder to debug. Instead, you can save them in memory, and just push a byte through the fd - that will make it show up in select. > > Moving the call to waitpid out of linux-nat.c, and to a target > > independent file, is a mistake - presumably that's just how you got it > > to work quickly? That's related to why it doesn't work for threads. > > The vital line is "options ^= __WCLONE" in the loop in linux_nat_wait. > > Without __WCLONE, you'll never see a wait status from a thread; with > > it you'll never see a wait status from the main program. > > Perhaps I can use __WALL as a catch all. There's supposedly some supported kernel versions left where that didn't work. Why can't you use the same code the existing support uses? I'm sorry I haven't been able to pitch in and help with this. I checked it out last week and started looking at it, but I'm buried in work past my eyeballs right now. -- Daniel Jacobowitz CodeSourcery