Re: asynchronous MI output commands

[Daniel Jacobowitz <drow at false dot org>]

On Sat, May 06, 2006 at 03:46:18PM -0400, Bob Rossi wrote:
> OK, we are going in circles. I currently have a goal of determining if a
> MI output is synchronous or asynchronous.

So you keep saying - but I'm not sure that you're asking the right
question.

> > I still don't understand the question - the point of categorizing
> > messages in this way.
> 
> 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.

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.

-- 
Daniel Jacobowitz
CodeSourcery