From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15174 invoked by alias); 26 Sep 2006 22:12:34 -0000 Received: (qmail 15166 invoked by uid 22791); 26 Sep 2006 22:12:34 -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; Tue, 26 Sep 2006 22:12:31 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-172.snap.net.nz [202.124.125.172]) by viper.snap.net.nz (Postfix) with ESMTP id C97687B9A51; Wed, 27 Sep 2006 10:12:26 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 3D0BEBE433; Wed, 27 Sep 2006 10:09:39 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17689.42274.369631.215081@kahikatea.snap.net.nz> Date: Tue, 26 Sep 2006 22:12:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? In-Reply-To: <20060926123757.GA9879@nevyn.them.org> 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> X-Mailer: VM 7.19 under Emacs 22.0.50.21 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/msg00156.txt.bz2 > 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. > 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. > Ideally you'd be able to reuse the signal handler logic (see the calls > to sigprocmask and sigsuspend) and thus not have a millisecond latency > and excessive spinning. That's actually a pretty important feature, > because context switching to gdb every millisecond or so is going to > really hurt performance of the debuggee. OK, a bit more homework then. Thanks -- Nick http://www.inet.net.nz/~nickrob