This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI/RFC] Emit ^running via observer.
> > 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