From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23229 invoked by alias); 6 Oct 2006 01:26:38 -0000 Received: (qmail 23221 invoked by uid 22791); 6 Oct 2006 01:26:37 -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, 06 Oct 2006 01:26:35 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GVeTx-0005E3-La; Thu, 05 Oct 2006 21:26:33 -0400 Date: Fri, 06 Oct 2006 01:26:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? Message-ID: <20061006012633.GA20001@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> <17701.43098.583849.540224@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17701.43098.583849.540224@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-10/txt/msg00029.txt.bz2 On Fri, Oct 06, 2006 at 01:50:34PM +1300, Nick Roberts wrote: > > 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. > > From the event loop, GDB needs to detect that a process/thread has changed > status and check for user input. If it does the first with sigsuspend, the > only way I can see how it can do the second is by using threads. This would > almost take us back to where we started. Correct. You can't do it quite the same way. The key is not sigsuspend itself, but the use of signals, and blocking them when you don't need them. The easy way to combine the two would be with pselect, but it's inadequately portable. Here's a bit from the man page of that function on my system, which explains a useful alternative: Since version 2.1, glibc has provided an emulation of pselect() that is implemented using sig- procmask(2) and select(). This implementation remains vulnerable to the very race condition that pselect() was designed to prevent. On systems that lack pselect() reliable (and more portable) signal trapping can be achieved using the self-pipe trick (where a signal handler writes a byte to a pipe whose other end is monitored by select() in the main program.) So when you want to wait, you make sure such a signal handler is installed for SIGCHLD, unblock SIGCHLD, and call select on a set of fds that includes the one written to by the signal handler. If you get a byte on that fd, you know there's a child ready to be waited for. When you're done waiting, you re-block the signal. It's possible to get spurious wakeups this way (for instance if a signal is received between the return of select and the re-blocking), but with a little care everything works out OK. This is actually pretty similar to the way you do it with threads. Does that make sense? -- Daniel Jacobowitz CodeSourcery