RE: MI output command error

["Dave Korn" <dave.korn@artimi.com>]

----Original Message----
>From: Bob Rossi
>Sent: 10 March 2005 14:40

> No, seriously though. Here is how I imagine a transaction between a FE
> and GDB.
> 
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"
>    -> FE sends a single MI input command
>    -> FE does I/O with inferior
>    -> GDB sends an MI output command
>    -> GDB alerts FE it is ready for a command via "(gdb)\r\n"

  Your imagination unfortunately fails to correspond to reality.  This is
*your* fault, not reality's.  What part of "asynchronous" don't you
understand?

> That's why I think the output
> 
>    (gdb)
>    444-exec-continue
>    444*running
>    444*stopped...
>    (gdb)
> 
> is better.

  Well, you're wrong.  "running" is the output from the exec-continue
command and it is synchronous: the exec-continue command executes, starts up
the inferior, prints out "running", and is then complete.  At that point the
inferior is running, but regardless of that, gdb is ready to take more
commands and so should prompt you.  The "stopped" output is an asynchronous
notification of an event that occurred while the inferior was running, but
that in no sense makes it output from the "exec-continue" command.  It can
occur spontaneously, it can happen sooner or later or not at all, and your
model of the interaction between FE and MI as being a completely predictable
one-command-one-reply set of exchanges is inaccurate, incomplete, and
inadequate to the task.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....