Re: MI: "^running" issues

[Bob Rossi <bob_rossi@cox.net>]

On Thu, Sep 06, 2007 at 10:46:21AM +0400, Vladimir Prus wrote:
> 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
> > 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?

This isn't necessarily true. It is not guarenteed that you will be able
to interupt the target. I'm pretty sure this won't always work with cygwin.

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

One example of a command that would be really useful would be 
-exec-interupt. I've discussed this extensively in the past. Sending a
^c to the inferior is not the perfect way to stop the inferior from 
running.  That's because typically a front end will put the inferior on
a tty to separate the output of the inferior from the output of gdb/mi.

As soon as this is done, it becomes unclear if the ^c should be sent to
the gdb/mi tty or the inferior stdin tty. Again, this is especially true
on windows.

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

Yeah, in general, I think this is how the MI stuff is developed though.
There doesn't seem to be anyone with a clear vision dedicated to gdb/mi. 
It's unfortunate. I mean, each front end developer of gdb/mi eventually 
becomes a gdb/mi developer. It's pretty sad.

Bob Rossi