Re: MI: "^running" issues

[Vladimir Prus <ghost at cs dot msu dot su>]

On Thursday 06 September 2007 07:19:11 Eli Zaretskii wrote:
> > 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".  

I hope you'll agree that "help" is not important enough to warrant
extensive gdb work, so let's drop this example immediately.

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

Technically speaking, you don't need async for that -- you can interrupt
the target, provide output, and then go on. Making this async will maybe
cut some fraction of section from the run time, why do we care?

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

Except for commands that run target, I know of only various get-symbol-list
commands that can take large time, and target memory access (load, disass,
raw memory access).  Are there some other commands?

While those indeed can be parallelized to some degree, I don't particularly see
the end-user use-cases where that's useful.

> So you are in effect questioning the value of 
> multithreading.

Multithreading is not a silver bullet. It should be used when appropriate.
Are you sure gdb code is thread-safe in any degree? 

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

This is argument by authority, I don't accept it.

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

I think at least some design should be present before coding, so it would
be reasonable that anybody who submits some async patches be ready to
explain the final goal -- what commands will be async, will it be just async,
or multithreaded, and what will be essential benefits for CLI user and for
frontends.

The way it stands now is more like "let's develop async mode, and then see
what commands we can run in async mode, and then see what benefit that
will have".

- Volodya