Re: non-blocking reads/writes and event loops

[Daniel Berlin <dan@cgsoftware.com>]

> Todd Whitesel wrote:
> > 
> > > > 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:
> > ...
> > > Just making certain that your eyes are open :-)
> > 
> > No doubts about that. That's why I said "long term goal"...
> 
> Unfortunatly, unless feasible intermediate steps are identifed that show
> how we can get from the eixsting GDB to this ``long term goal'' it will
> just remain a long term goal :-(

Almost as if planning something large was an integral part of getting it
done.
Strange.

> 
> To that end, I can see several strategies.  Interestingly at least one
> discards the assumption that the event loop should _not_ be re-entrant.
> 
> o	invert the targets first
> 		
> 	This would be implemented
> 	using something like:
> 
> 	(gdb) ->do-command
> 	  -> target_xfer_memory()
> 	    -> target->request_data()
> 	    while need more data, run inner event loop
> 	       <- target-supply-data()
> 	    <- return data
> 
> 	That is, the GDB core would continue
> 	to assume that things are blocking
> 	but the targets would internally
> 	be implemented as non-blocking.
> 
> 	Care would be needed that the internal
> 	event loop didn't re-call the CLI et.al.
> 
> 
> o	invert the expression evaluator first
> 
> 	In this case, legacy targets would
> 	be wrapped so that:
> 
> 	(gdb) ->do-command
> 	   -> target_memory_request()
> 	     -> target_xfer_memory ()
> 	     schedule event to supply
> 	     returned data to expression evaluator
> 	-> supply_data to expression evaluator
> 
> 
> (wonder if this makes any sense).  Of course there is option three, both
> of the above.
> 
> For what its worth, for some reason I have preference for the first
> option - not sure why, perhaphs it is simply that I'm more familar with
> targets and back-ends.
> 

> As I noted above, one of the original design decisions for the event
> loop that it not be re-entrant.  The above questions that decision. 
And rightfully questions it, IMHO.

> Another decision was that GDB's core assume no threads.  Should that too
> be questioned?

I have no problem with using threads, i do it on a daily basis. The only
issue i would have with GDB's core using threads would be that we take
care not to assume that everyone has pthreads. If we go with threads, i
would ask we add a simple abstraction, like most portable things using
threads (Just from personal experience, Python's source comes to mind as 
something that works with threads, using "easy to make work on a given
platform supporting threads", and provides all the thread functionality
people ask for. Works on BeOS, QNX, and every other python 
supported platform that has threads).

The question about whether we *should* use threads is a different one
altogether.
The real question splits into "Are there parts of gdb where we could be
doing
processing that isn't dependent on other processing, and we therefore are
possibly wasting time on MP systems by not having each done in a thread"
and "Are there parts of GDB where we could simplify code flow by using
threads".

 >
> enjoy, > Andrew >