From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6441 invoked by alias); 6 Oct 2006 02:13:31 -0000 Received: (qmail 6432 invoked by uid 22791); 6 Oct 2006 02:13:30 -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; Fri, 06 Oct 2006 02:13:26 +0000 Received: from kahikatea.snap.net.nz (p202-124-124-110.snap.net.nz [202.124.124.110]) by viper.snap.net.nz (Postfix) with ESMTP id DFBDB7B80DD; Fri, 6 Oct 2006 15:13:21 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 16183BE43F; Fri, 6 Oct 2006 15:10:38 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17701.47901.123920.954707@kahikatea.snap.net.nz> Date: Fri, 06 Oct 2006 02:13:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? In-Reply-To: <20061006012633.GA20001@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> <17701.43098.583849.540224@kahikatea.snap.net.nz> <20061006012633.GA20001@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.50.23 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/msg00030.txt.bz2 > 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? Yes I think so. I don't quite follow the explanation of pselect in the manpage but I think you're saying that the signal handler for SIGCHLD will run even when GDB is already in select, and can get GDB's attention by writing to a pipe with a file descriptor that select is watching. -- Nick http://www.inet.net.nz/~nickrob