Re: libGDB architecture

[Andrew Cagney <ac131313@cygnus.com>]

Todd Whitesel wrote:
> 
> > In the first case, there is a chance that the target could die part way
> > through an exchange.  That in turn could cause GDB to hang until a timer
> > kicks in.  It was felt that the probability of this was low and the
> > amount of effort needed to handle this case providing marginal return.
> >
> > As a second pass (or as contributed code) this can be re-worked into a
> > simpler interface.
> 
> Reasonable enough.
> 
> I must say though, one of my biggest complaints against the innards of MULTI
> was that the synchronous heritage from ptrace() was rampant and was lousy for
> embedded, where we can have targets dying and the debugger UI freezing solid
> while a compile is going on in another window ... customers really hate that.
> 
> Various attempts to solve this often resulted in the UI event loops being
> re-entered, which has its own host of dangers. I fought hard for the idea
> of state-machining tasks that block in vulnerable places, so we could just
> call everything from the top of the event loop and not have problems. The
> people whose backing I needed for it pooh-poohed the idea for a couple years,
> but about the time I was quitting I discovered that the guy promoted to head
> up MULTI had quietly started working on it and was mostly finished.

I believe that Elena has been hitting her head against that one for some
time.
In the longer term I agree that things like remote.c and ser-* should be
made into separate state machines along the lines you suggest.  Just not
this week :-)

	Andrew