Re: [MI/RFC] Emit ^running via observer.

[Nick Roberts <nickrob@snap.net.nz>]

 > > 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.


-- 
Nick                                           http://www.inet.net.nz/~nickrob