Re: MI: "^running" issues

[Eli Zaretskii <eliz@gnu.org>]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Wed, 05 Sep 2007 22:41:38 +0400
> 
> > Asynchronous execution means that some GDB commands can be run while
> > GDB waits for the target to stop.  It is good for users because you
> > can do something useful while you wait for the target to stop.
> 
> Unfortunately, I never saw more concrete details.

That's because introduction of asynchronous execution into GDB was
never finished.

> What commands are actually meaningful to emit while target are
> running

Anything that does not need the target itself, or modifies its state.
For example, "help".  A less trivial example is "info break" (to see
what breakpoints were already hit during execution up to now, in case
your "commands" for the breakpoints continue the target).

Note that I'm not actually saying these commands will work
asynchronously in the current GDB, as the implementation of async
execution was never finished, AFAIK.

> and are those commands of big enough value to user to warrant
> extensive coding?

"Big enough" is in the eyes of the beholder.  In principle, every
command in GDB that could take a long time could run in the
background, and GDB could be free to accept other commands in the
meantime.  So you are in effect questioning the value of
multithreading.

As another data point, the people who wrote the infrastructure for the
async execution were two long-time and experienced GDB users and
developers, and they obviously thought it was worth coding.

> Can interested parties document those commands at GDB Wiki, or even
> in email?

The list depends on what we decide to code, so I don't think anyone
can publish it now.