This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: non-blocking reads/writes and event loops
- To: ac131313 at cygnus dot com (Andrew Cagney)
- Subject: Re: non-blocking reads/writes and event loops
- From: Todd Whitesel <toddpw at windriver dot com>
- Date: Tue, 20 Jun 2000 03:43:17 -0700 (PDT)
- Cc: toddpw at windriver dot com (Todd Whitesel), jingham at apple dot com (Jim Ingham), gdb at sourceware dot cygnus dot com, insight at sourceware dot cygnus dot com ("Insight (GDB GUI)")
> 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