Re: non-blocking reads/writes and event loops

[Andrew Cagney <ac131313@cygnus.com>]

Todd Whitesel wrote:
> 
> > However, threads may need to be used in the case where you only have a
> > blocking API to control the inferior, but in that case all you are doing is
> > using threads to fix this local deficiency, not pushing it into the gdb
> > architecture.  I think this is managable.
> 
> Agreed. If the API designers are dumb enough to trust threads absolutely,
> and don't give us an option, then well, that's life.

For what it is worth, here is the ``It is hard'' reason number two:

In addition to the expression evaluator, every physical target (that is
the bit that knows how to read/write memory and registers) needs to be
inverted.  The basic programming model used when developing them
requiring a full rewrite.

At present a memory/register IO looks like (vaguely):

	event-loop
	   tty event: (gdb) print ...
		-> expression-evaluator
		    -> target->read()
		        -> os/remote->read()
		        <- data
		    <- data
		<- evaluate
	    print

at the target level, since we are inverting things, it would need to be
broken down into several transactions:

	event-loop
	    tty-event: (gdb) print ...
		-> expression-evaluator
		    -> target->request_read ()
		        -> os/remote->request_read ()

	event-loop
	    os/remote-event: some data ready
		-> os/remote->supply_some_of_data()

	event-loop
	    os/remote-event: some data ready
		-> os/remote->supply_rest_of_data() (all data ready)
		    -> target->supply_data()
			->expression_evaluator->supply_data()

	event-loop
	     ->expression-evaluator->display()

(please don't nit-pick on the detail :-).  The point being that you are
introducing a fundamentally different programming model into _all_
levels of GDB.  You are no longer using procedures but instead passing
around messages and writing state machines or similar.  All of which are
not mechanical.

Just making certain that your eyes are open :-)

	Andrew