Re: MI output command error

["Eli Zaretskii" <eliz@gnu.org>]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 13 Mar 2005 22:35:02 +1300
> Cc: drow@false.org, dave.korn@artimi.com, kostik@ispras.ru,
> 	gdb@sources.redhat.com
> 
>  > I'm all for documenting this in some useful way, but I fail to see how
>  > could this be done.  Describing the async operation itself is already
>  > a big challenge, as the details are extremely confusing, unless you've
>  > read the code several times and have a good understanding of the
>  > underlying system calls (like `poll' and `select').  Differences
>  > between interpreters add another dimension of complexity to this.
> 
> Well for someone to be able to code it must mean that it can be documented.
> But if you mean that those who did the coding are no longer available to
> do the documenting, then I can see this would be a difficult task.

People who code are generally never available for documenting (present
company excluded), that's why gdbint.texinfo is in such poor shape ;-)

But what I meant was that, knowing what I do about the event loop, I
don't know how to document it in a useful way, because talking about
async operation is generally hard.  Of course, I will applaud anyone
who tries, and will try to help such an effort ion any way I can.

> Actually if the asynchronous operation was working, I'm not sure what I would
> do with it. When I debug, I'm used to waiting for execution to stop.

Precisely.  That is one reason why async CLI operation was never fully
implemented: the event loop is ready for it, but the CLI layer simply
waits until some event comes in.