From mboxrd@z Thu Jan  1 00:00:00 1970
From: Todd Whitesel <toddpw@windriver.com>
To: ac131313@cygnus.com (Andrew Cagney)
Cc: toddpw@windriver.com (Todd Whitesel), jingham@apple.com (Jim Ingham), gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com ("Insight (GDB GUI)")
Subject: Re: non-blocking reads/writes and event loops
Date: Tue, 20 Jun 2000 03:43:00 -0000
Message-id: <200006201043.DAA22919@alabama.wrs.com>
References: <394DAD8D.C100E36F@cygnus.com>
X-SW-Source: 2000-q2/msg00288.html

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

IMHO the simplest way is always to invert from the top down, so things are
just merged into the main event loop as you go.

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

Well that depends on how much of the event loop machinery is used by the
low-level inversion. If it calls things that assume a single global event
loop, then we have a problem.

If you have to invert a low-level algorithm early on, there are a couple
ways to do it:

  1. make the event loop machinery instantiable and use a new instance of it.
	THIS IS ARGUABLY NECESSARY FOR MULTIPLE TARGET CONNECTIONS ANYWAY.

  2. do not attempt to provide full non-blocking facilities yet, just show
	that the low-level code works correctly in inverted form -- its
	sub-event loop just calls it repeatedly, so it still blocks but at
	least uses the new code structure.

IMHO either is fine; which one you use depends on whether you have gotten
the instantiable event loop machinery working yet.

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

I don't mind specific native target support assuming threads.

However using threads as a general method of avoiding the inversion of
GDB core code is a COP OUT.

-- 
Todd Whitesel
toddpw @ windriver.com