This is the mail archive of the
mailing list for the GDB project.
non-blocking reads/writes and event loops
- To: GDB Discussion <gdb at sourceware dot cygnus dot com>, "Insight (GDB GUI)" <insight at sourceware dot cygnus dot com>
- Subject: non-blocking reads/writes and event loops
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 12 Jun 2000 20:12:22 +1000
- Organization: Cygnus Solutions
- Reply-To: GDB Discussion <gdb at sourceware dot cygnus dot com>
[this is a cross post, reply-to has been set to gdb@sourceware]
Two architectural changes introduced in 5.0 were the the event-loop and
the targets ``remote async'' and ``remote extended-async''. J.T.'s
recent posting about memory read/write raises a second significant issue
related to the event-loops, GUI's and async but first some background.
The event-loop provides a mechanism that allows GDB to block on more
than one input (or output) source. For instance, GDB might be blocked
waiting for both the remote target and the user input. As events
arrive, the event-loop dispatches them.
The async/extended-async targets exploit the event-loop so that, while
the target is running, the user can still enter various commands. For
(gdb) target extended-async ....
(gdb) help ...
Breakpoint #1 reached, ...
In getting this working, numerous problems were identified and several
compromizes were made (look for FIXMEs, especially in remote.c).
The main compromize is to do with when the target has halted. While the
target is running the async target code returns control to the main
event-loop. When the target starts ending it stopped packet, or when
the target is assumed to be halted, the code revers to polling. Memory
reads/writes and the like are blocking operations - they do not return
control to the event loop. For instance:
(gdb) print foo
gdb calls target-vector to read memory (&foo, sizeof(foo))
target-vector ``calls'' remote to read memory from &foo
target-vector receives data from remote
gdb receives data from target-vector
$1 = "foo"
The rationale behind the decision to block in this case was very
pragmatic - it wasn't going to be feasible to invert (as was done to
serial.c) all of GDB (so that everything was event based) in a single
The consequence is that, during these blockages, GDB is slower than
dring normal operation - for the CLI the problem isn't too noticable.
For the GUI, however, it is very noticable. As a result, the built in
GUI (ex insight) is forced to use other means to avoid this slugishness
- during those blocked reads a timer is set up and that is used to
process the GUI events (see ui_loop_hook() and
The thing that needs to be decided is how far GDB should be pushed to
address this problem. Should GDB continue to be pushed to the point
where everything is event based or should, the current compromise remain
where a GUI is unable to exploit GDBs event-loop.