This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [MI] Synchronous event notification
- From: Keith Seitz <keiths at redhat dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: <gdb at sources dot redhat dot com>
- Date: Fri, 24 May 2002 15:26:50 -0700 (PDT)
- Subject: Re: [MI] Synchronous event notification
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