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

[Vladimir Prus <vladimir@codesourcery.com>]

On Saturday 28 June 2008 04:14:27 Nick Roberts wrote:
>  > > mi-async.exp is a test for async mode, so is not expected to pass in sync
>  > > mode.
>  > 
>  > That's the question -- what about this test is specific to async mode?
> 
> 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.

>  >...
>  > > It's not a problem if async mode becomes the default, which is my
>  > > understanding.  
>  > 
>  > Not mine, unfortunately. We can't even make all target always have at least
>  > one element in thread list -- which is much simpler change.
> 
> Maybe that's a requirement of non-stop mode but I'm not sure that this is
> relevant here, i.e. with just async mode.

I meant relative complexity of things. Making the thread list always have a single thread 
is relatively straight-forward, but still, making this happen for 
*all* targets is going to take lots of time. Adding async support for a target
is considerably harder -- as linux-nat.c changes clearly demonstrate. Therefore, 
I don't expect that GDB will support async on a wide set of targets anytime soon.

- Volodya