Re: non-blocking reads/writes and event loops

[Jim Ingham <jingham at apple dot com>]

on 6/16/00 2:54 PM, Nick Duffek at nsd@redhat.com wrote:

> On 12-Jun-2000, Andrew Cagney wrote:
> 
>> 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.
> 
> On 12-Jun-2000, Jim Ingham wrote:
> 
>> 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.
> 
> [...]
> 
>> So my vote is to eradicate ALL the blocking behavior, and make GDB a pure
>> event driven application.
> 
> Does that include file I/O?  Reading a core file over NFS could freeze a
> GUI for quite a while.
> 
> If so, then we'd need to invert BFD as well.

Ideally, yes we should do this.  But this can be a gradual process, and I am
less worried about reading core files, since this is a single atomic
operation, and thus easier to protect against with timeouts, etc...

> 
> I'd rather see the GUI problems solved by two processes:
> (1) the GDB core, which talks to inferior processes;
> (2) the user interface, which talks to (1) over a pipe using a
> well-defined protocol.
> 
> [Credit to Chris Faylor and Jim Blandy for suggesting this approach.]

While I have a lot of respect for these two folks, this is hardly their
idea.  This is the approach that most GUI interfaces to GDB have taken over
the years.  

I am of two minds here.  In many IDE type applications, there is a desire to
host the debugger IN the IDE, and breaking out the debugger engine into a
separate process is certainly attractive.  It also does (with proviso's that
I note below) help solve the problem of gdb blocking without having to do
much work.  

On the other hand, GDB knows a lot about the application that it is
debugging, and in big programs there is a LOT to know...  So having an
in-process gui is also attractive, since you can get very quick and direct
access to all this knowledge, without having to package it into strings, and
unpackage it at the other end.

Doing things like presenting all the globals available to a given module, or
sometimes even all the local variables, can involve a lot of data flow.
Ditto for memory views, and even some crazy processors that have hundreds of
registers.  

Note also that this data has to be updated on EACH STEP, while the user
expects steps to complete quickly.  And most people are pretty unforgiving
about both performance in this area, AND the UI being out of synch with the
inferior at each stage.  If there is a delay in stepping, you interrupt the
concentration of the user as they are trying to chase the flow of control of
their program.  And if data is ever out of synch (even if you try to get
around this by coloring un-updated data or some such) you break the user's
trust in the information being presented.  Maintaining this trust is also
essential to allowing the user to settle into and concentrate on the
difficult problem of debugging...

So I still think it is important to try to make it easy to support
in-process GUI's to gdb like Insight.

> 
> The user interface could be a GUI, a command-line interface, Emacs, etc.
> Pipes are non-blocking, so a GUI need never freeze due to blocking
> debugging calls.

Note that even when the UI is in another process, it is really nice to have
a non-blocking gdb under the hood.  It makes it easier/possible to implement
things like progress bars, etc.  It also makes the question "Has gdb gone
south, has a board gone south, or is it just waiting a long time to do
something?" easier to ask & answer.  Moreover, the ^C mechanism for
interrupting gdb is pretty fragile as well, or at least it caused us LOTS of
problems with Insight...

There are also some interrupt type things that are quite useful to have, and
which would be more safely implemented in gdb.  One example of this is the
ability to insert breakpoints while the inferior is running.  If you have
ever used a debugger that supports this, I think you will agree this is
REALLY useful.  You can of course implement this by sending a ^C to gdb from
the UI, inserting the breakpoint, and then continuing the inferior.  But I
think (a) it is silly for each GUI to have to implement this separately, and
(b) gdb is better equipped to do this correctly than a UI which, after all,
has fairly limited knowledge of the inferior.  The architecture for this
becomes much cleaner if gdb is live and able to respond to the client at all
times.

> 
> As far as I can tell, this provides all the benefits of fully
> event-loopizing GDB without the cost of making GDB hugely more complex.

I don't think that the END RESULT of event loop-izing gdb would be to make
GDB hugely more complex.  In many cases, I think that it would make the
architecture much simpler and cleaner, since you would not have modal loops
hiding out all over gdb, but rather a very simple event loop, and,
hopefully, a standard mechanism for waiting in the event loop that all the
different modules of gdb could share.  Not to say that the PROCESS of
getting GDB to this point would be easy, as Andrew points out...

> 
> Toward implementing this approach, it might be helpful to have a library
> for storing and transferring parts of GDB state like breakpoints,
> watchpoints, and "set" values.
> 
> Such a library could be used by a GUI e.g. to maintain a copy of the
> breakpoint list, so that it could perform the equivalent of "info
> breakpoints" without blocking.

This sounds okay, but do we really want to go the route of prospectively
priming the GUI with ALL the bits that GDB knows about, and which the UI
might want to know, at each step, just so we don't have to make gdb
non-blocking?

> 
> It could also be used to implement the saving of breakpoints, watchpoints,
> and other state across GDB sessions.
> 

This sort of stuff is very useful, though I would want to make sure that
this library is more of a library, i.e. useable in process as well as for
client apps.  The MI interface is a step towards this, though it still
suffers from the "distributed" nature of information gathering in gdb.  But
I think this is a separate issue from the blocking behavior of gdb.

Jim