This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI output command error
> 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.