Re: non-blocking reads/writes and event loops

[Andrew Cagney <ac131313 at cygnus dot com>]

Nick Duffek wrote:

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

Some how, I suspect not.  Some operations, such as reading/writing an
executable will continue to be blocking.  If an NFS partition freezes
then I suspect a hung GDB is the last thing on the users mind :-)

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

FYI, the ``well defined protocol'' is called MI :-)

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

Unfortunately, it avoids rather than solves the problem.  One thing we
found from MI is that even after you separate out the GUI, GDB, in the
end, still needs to be 100% non blocking.  

Consider a GDBng (GDB 6) that is trying to talk to two (or more) active
remote targets.  The current remote.c blocks out all other activity
while it is communicating with a single target.  Just like it can
currently block out the GUI, it would also block out the processing of
those other targets.  While the user is surprisingly tolerant of a 5-30
second hiccup, the typical protocol tends to be be surprisingly
intolerant :-)

	Andrew