Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Keith Seitz <keiths at redhat dot com>]

On Tue, 1 Oct 2002, Jim Ingham wrote:

> BTW, I haven't seen the actual change Keith is planning here.  Will he 
> be sticking the command sequence cookie in the async result?  His 
> example didn't show the cookies.

For the record, the proposed change would look like:

(gdb)
200-break-insert main
=breakpoint-create,number="1"
200^done
(gdb) 

> Seems to me that reporting command results as an async notification 
> means that we are breaking the tie between the command and its results. 

And is that necessarily bad? (More on my confusion below...)

>   It was very nice that I could issue a bunch of commands at some point 
> in the GUI code, then at another place gather up the results, and match 
> them to the initial commands by using the sequence ID's.

I'm afraid that I'm not following. Could you please expound? Why would 
you want a tight coupling of commands and their results? What's wrong with 
just issuing a command at GDB and waiting for GDB to tell you that
it's done something? It seems to me that the less serialization that a UI 
does, the more time it has to spend in its event loop and the more 
responsive it will feel to the user (barring the java way: create a 
freakin' thread for everything).

> In the new way of doing things, we have to parse more carefully, and 
> assume that the =breakpoint-create that we just got was the one that 
> came from the -break-insert in the output just above it.  It makes the 
> client stream parser have to be more stateful that in the mi0 version, 
> which doesn't seem to me all that good an idea.  If the async event has 
> the cookie in it, this will be a little better, though it still means I 
> have a two-step accumulation phase for each command (wait for the async 
> result with the right cookie, then the done with the right cookie...)

Ditto the above. Maybe -break-insert and =breakpoint-create are bad 
examples(?), but I am not able to imagine why it would matter which 
command elicited the notification. Commands are issued, and something 
happens. The only case I can imagine where this is important is when 
an error occurs setting the breakpoint, but MI will (and will 
continue) to report errors immediately.

Maybe something related to async targets? (BTW, there is no reason why 
I/we cannot/could not put the old behavior back for an MI0 target, if 
'mi0' were sticking  around, which is a decision I want nothing to do 
with, actually.) One is still pretty screwed, though, when 
"interpreter-exec" is used, unless we revert from async notification back 
to serial notification via hook hack that you're using.

<devil's advocate>
As far as the versioning thing goes, I must say that I don't really care, 
(not that my opinion matters), but I can understand why some on this list 
would be less sympathetic with objections to dropping mi0 coming from 
Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of 
stuff, but only managed to "submit" a giant distribution tarball of their 
modified GDB. I wouldn't be too suprised if some thought that Apple was 
taking advantage of the public's work. Mind you, I'm not saying that any 
of this is true, but I wouldn't be suprised if some one reading this list 
felt that way.
</devil's advocate>

Keith