From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30087 invoked by alias); 30 Aug 2006 23:45:41 -0000 Received: (qmail 30078 invoked by uid 22791); 30 Aug 2006 23:45:40 -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 23:45:38 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-70.snap.net.nz [202.124.125.70]) by viper.snap.net.nz (Postfix) with ESMTP id 481237B8872; Thu, 31 Aug 2006 11:45:34 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id AD829BE446; Thu, 31 Aug 2006 11:43:24 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17654.8858.706203.208241@kahikatea.snap.net.nz> Date: Wed, 30 Aug 2006 23:45:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Merge of nickrob-async-20060513 to mainline? In-Reply-To: <20060830214257.GA5397@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> 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/msg00265.txt.bz2 > > Instead of GDB waiting for the enferior to stop directly, it creates a > > signal thread to do that. This means that the main thread can continue to > > process the event loop. When the inferior does stop, the signal thread > > writes to a file which GDB detects through handle_file_event in the event > > loop. It then calls inferior_event_handler. > > OK, this is easily mimicable without threads, at least on GNU/Linux. Easy being in the eye of the beholder! > On Cygwin/Windows I imagine we'd want to use threads, but the tradeoffs > there are somewhat different :-) As there are platform specific changes e.g to linux_nat_attach, linux_nat_wait, i386_linux_resume etc, I guess they need to be added on a case by case basis. Presumably this could be done incrementally i.e we could merge asynchronous operation on GNU/Linux into GDB without waiting for it to work on Cygwin/Windows. > > The manpage just says: > > > > WNOHANG > > return immediately if no child has exited. > > > > but what value does it return with? Does GDB ignore SIGCHLD events so it > > can detect state changes through wait? > > If that's all it says I recommend a better man page :-) > > waitpid(): on success, returns the process ID of the child whose > state has changed; on error, -1 is returned; if WNOHANG was > specified and no child(ren) specified by pid has yet changed > state, then 0 is returned. Doh! > Different ports of GDB treat SIGCHLD differently. linux-nat.c, for > instance, blocks it so that it can use sigsuspend. Instead, we would > have to register handlers for sigchld events somehow (probably using > the same infrastructure used for SIGINT to quit operations). > > I can work on this, though not right away. Thanks. -- Nick http://www.inet.net.nz/~nickrob