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

[Vladimir Prus <vladimir at codesourcery dot com>]

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