From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: non-blocking reads/writes and event loops
Date: Mon, 12 Jun 2000 03:13:00 -0000
Message-id: <3944B786.A16E9A2F@cygnus.com>
X-SW-Source: 2000-q2/msg00253.html

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