non-blocking reads/writes and event loops

[Nick Duffek]

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.

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.]

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.

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.

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.

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

Nick