Re: non-blocking reads/writes and event loops

[Jim Ingham <jingham at apple dot com>]

Hi, Andrew,

I think that the day has come when we need to be serious about making gdb a
really good backend for GUI's.  The percentage of programmers who are happy
with a purely command line tool is going down with time, and the advantages
to a good GUI Debugger are pretty clear.  For this to happen, we need to
remove as many of the fragilities of GDB as possible, and this blocking
behavior is a prime candidate.

One thing to remember about this is that any blocking operation that can
fail, particularly ones that have fairly long timeouts (or in some cases
like the RDI code, none at all) becomes a point of fragility for any GUI
based on top of gdb.  The result of not catching a potential hanging point
are serious, the application goes dead, and you have to kill it!

Having potential traps like this around in the code means the GUI will have
to analyze EVERY call down into gdb to see if it is going to block, and then
set the timers.  Often you can't really get "close" to where the blocking
call is, either, because there is a lot of setup work after the GUI hands
control off to core gdb, so doing this is not as easy as it seems.  And
having timers firing off when you are in the middle of other work also makes
the GUI coding hard to handle.

So my vote is to eradicate ALL the blocking behavior, and make GDB a pure
event driven application.  In the cases where you can't avoid blocking calls
(like ptrace calls, for instance) we should consider spinning a helper
thread, and doing the work there.  I am not in favor of a thread-happy
approach for gdb, but the careful use of short-lived threads to do
particular tasks is a lot more stable than forcing interrupt-driven
programming on the unhappy GUI's that attempt to use gdb...

Just my .02

Jim.


> Hello,
> 
> [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
> instance:
> 
> (gdb) target extended-async ....
> (gdb) run&
> (gdb)
> (gdb) help ...
> ....
> (gdb) 
> Breakpoint #1 reached, ...
> (gdb)
> 
> 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 blocks
> target-vector receives data from remote
> gdb receives data from target-vector
> 
> $1 = "foo"  
> (gdb)
> 
> 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
> hit.
> 
> 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
> gdb/gdbtk/generic/gdbtk-hooks.c:x_event()).
> 
> 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.
> 
> Andrew
>