From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27286 invoked by alias); 28 Jun 2008 09:49:05 -0000 Received: (qmail 27278 invoked by uid 22791); 28 Jun 2008 09:49:05 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 28 Jun 2008 09:48:47 +0000 Received: (qmail 29213 invoked from network); 28 Jun 2008 09:48:46 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Jun 2008 09:48:46 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI/RFC] Emit ^running via observer. Date: Sat, 28 Jun 2008 10:44:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sources.redhat.com References: <200806140108.24047.vladimir@codesourcery.com> <200806280949.09304.vladimir@codesourcery.com> <18534.1805.519374.851454@kahikatea.snap.net.nz> In-Reply-To: <18534.1805.519374.851454@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806281348.44175.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00531.txt.bz2 On Saturday 28 June 2008 13:40:29 Nick Roberts wrote: > > > Async mode decouples the output from the input. This allows a CLI command > > > that executes the inferior to (indirectly) generate MI output. That's why > > > I was interested in async mode and that's what this test is for. The work > > > has actually been done for more general reasons, such as non-stop mode. I > > > think the MI output is just a fortunate side-effect. > > > > Err, async mode does one thing -- allows commands to be processed while > > inferiour is still running. Unless you explicitly make use of this > > functionality, there's no difference from sync mode. (Of course, there's a > > bunch of checks for target_can_async_p in GDB code, so some difference in > > output is possible, but in theory there should be none). I don't know what > > you mean by decoupling output from the input -- for example, then *running > > notification is emitted for CLI just fine, and this does not require async > > mode. > > This is my understanding: > > *running is presumably an observer that is only set in MI and fires whenever > execution (re)starts. It doesn't depend on the (immediate) interpreter. In > sync mode when a CLI command starts execution, GDB waits for it to stop before > switching back to MI and returning to the event loop. In async mode it > doesn't, and when inferior_event_handler runs after execution has stopped, > GDB has already switched back to MI and so prints MI output. I still don't understand what you mean by "decouples the output from the input". GDB, both in sync and async mode is in perfect position to print things as it sees fit. And MI notifications don't actually care about 'current interpreter'. The *only* fundamental limitation of sync mode is that no command will be processed when the target is running. Am I missing something? - Volodya