Re: asynchronous MI output commands

[Bob Rossi <bob_rossi at cox dot net>]

> > I was hoping to tell the front end if the command was asynchronous or
> > not. There is a use in knowing if the command is asynchronous or not.
> > First of, if the command is asynchronous then I don't have to probe the
> > parse tree to determine if it represents the results to say,
> > -file-list-exec-source-file or some other commands. I know when building
> > the ADT for the FE that it's an asynchronous command, and that limits
> > the amount of probing in the parse tree I have to do.
> 
> That's not the difference between synchronous and asynchronous, in MI:
> think of it instead as the difference between synchronous and
> everything else.  A synchronous response from MI corresponds to a
> front-end command.  Everything else corresponds to other state changes,
> which may be related to some command or not, in a less than obvious
> way.

OK, with that information, I see it is impossible to tell just from 
looking at the MI output, to determine if the command is synchronous 
or not. Look below for a solution to this problem for me.

> You can easily categorize a ^done or ^error response as synchronous.
> Other responses are more difficult to associate with a command, because
> they weren't directly issued as the response to a command.
> 
> > It could output
> > 
> > -file-list-exec-source-file
> > %-file-list-exec-source-file
> > ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> > (gdb)
> 
> Accomplishing what?  This is synchronous.  It's a response to the
> previously issued command.  The front end knows exactly what its
> previously issued command was, I hope.

Hmmm. That's interesting, I was hoping to not need to know what the
input command was in order to parse and build an ADT for the output. In
general, I think it would be appropriate if the MI output described
itself well enough that no other information was needed to understand
it, including the MI intput command.

I think I could accomplish this task, as well as understand what is
synchronous and asynchronous by adding a little bit of output to each
synchronous command like shown above. Showing the MI command that GDB 
is responding to in the MI output would do just the trick. Would a
simple patch that changed the output like this be welcome?

from
    result-record ==>
	[ token ] "^" result-class ( "," result )* nl
to something like

    result-record ==>
	[ token ] mi-input-command "^" result-class ( "," result )* nl

The above is just a simple suggestion to show the goal. I'm not sure if
that would be the best place to change the code. I'd like to do it in a
way that didn't break the MI output syntax.

Thanks,
Bob Rossi