Re: [MI] Synchronous event notification

[Keith Seitz <keiths@redhat.com>]

On Fri, 24 May 2002, Andrew Cagney wrote:

> So:
>
> ^done,result=...,events=...
>
> So that, for a ``synchronous'' command the events just get bundled with
> the result.  Sounds ok, definitly has a certain elegance - here is the
> result, here are all the sideeffects.

It has that as an advantage, but it also has one minor disadvantage: we'd
be processing events for synchronous targets and async targets
differently.

> One question, what about a more asynchronous operation?  A running
> target starts loading shared libraries, inserting breakpoints, running
> scripts, et.al.  There the synchronous nature is gone.  I guess:
>
> - notify of all the events when the target next ``stops''
>
> - notify the events on-the-fly (possibly incuring an overhead?)

YES! This is exactly what I would prefer to see done. _All_ events come
out on a channel. Then it won't matter if the target is sync or async:
events are async in nature:

(gdb)
-interpreter-exec console "break foo"
&Breakpoint 1, ...
*breakpoint-create,bkpt=...
(gdb)
-break-insert main
*breakpoint-create,bkpt=...
(gdb)

UIs prefer to respond to events when something happens. In the later case
above, we've asked gdb to install a breakpoint at main, but the UI won't
actually do anything (like update breakpoint markers or breakpoint
windows) UNTILL it gets the event from gdb.

So, if we need to vote, I vote that we output aync events all the time.
(Of course, this would mean we really need to get target output nailed
for the natives, but that's another battle.)

Keith