Re: non-blocking reads/writes and event loops

[Jim Ingham <jingham at apple dot com>]

on 6/19/00 4:08 PM, Nick Duffek at nsd@redhat.com wrote:

> On 19-Jun-2000, Jim Ingham wrote:
> 
>> Note also that this data has to be updated on EACH STEP, while the user
>> expects steps to complete quickly.  And most people are pretty unforgiving
>> about both performance in this area
> 
> Shared memory could minimize the performance impact.  In fact, on a
> multi-processor host, the 2-process approach conceivably could result in
> snappier GDB response.

I would hesitate to use shared memory to communicate between gdb and the UI,
unless I knew that I was only going to have to support a few platforms,
since it is pretty platform dependent...  Maybe if you wrapped it in some
abstraction like CORBA...

> 
>> AND the UI being out of synch with the
>> inferior at each stage.
> 
> I don't understand how data display synchronization is a 1-GDB-process
> vs. multi-GDB-process issue.  If data is being displayed while the
> inferior is running, GDB's data display will lag behind reality regardless
> of whether the display is happening in a front-end UI process.  If the
> inferior is stopped, the data display will be accurate.
> 
> What am I missing?
> 

The processing that goes into packing all the information you need to
present into string based data structures on the gdb end, shipping it across
the pipe, and then unpacking it on the other end.  With a lot of data, this
can be pretty noticable.  You can ameliorate this by using shared memory,
and using something like CORBA to transmit the data in a more structured
form.  But this is not a negligible concern, in my experience.

>> There are also some interrupt type things that are quite useful to have, and
>> which would be more safely implemented in gdb.  One example of this is the
>> ability to insert breakpoints while the inferior is running.
> 
> Isn't this already addressed by the asynchronous execution feature?

Yes, this example falls in the realm of execution, so its okay (except that
of course there is only one target that actually has an async equivalent.)

> 
> I see how asynchronous breakpoints could be useful, and I agree that they
> should be implemented directly rather than via ^C.  I'm arguing against
> making things like inferior memory I/O be asynchronous.
> 

The problem that I have seen is that many things can go wrong in the
communication between the debugger and the target, and if gdb is hung
waiting on something to happen, then the UI can't really give good feedback
as to what is going on.  This leads to times where the UI is alive, which is
good, but has no idea of what GDB is doing.  I can usually reset in this
case, but this is not all that satisfactory, since I don't know from the UI
what went wrong...

>> I don't think that the END RESULT of event loop-izing gdb would be to make
>> GDB hugely more complex.
> 
> I once modified a piece of software to do asynchronous magnetic tape I/O.
> It was complex and messy to keep track of the state necessary to make that
> one part of the software work asynchronously, but there was a big
> performance payoff that made it worthwhile.
> 
> Making all parts of GDB work asynchronously seems very complex and messy,
> and I still don't see the big payoff.  Of course, I'm extrapolating the
> complexity from another software project, so perhaps I'm overestimating
> it.

I don't know.  Tcl is pretty much all event driven.  It took a lot of work
to come up with a model that works well for all sorts of different input
sources, and on a wide variety of different platforms, but having done the
work, it is not that hard now to plug in new sources, and get them to play
nice.  I guess I am saying that we have some models where, once correctly
juked around, the results are quite nice.

> 
>>> Toward implementing this approach, it might be helpful to have a library
>>> for storing and transferring parts of GDB state like breakpoints,
>>> watchpoints, and "set" values.
> 
>> This sounds okay, but do we really want to go the route of prospectively
>> priming the GUI with ALL the bits that GDB knows about, and which the UI
>> might want to know, at each step, just so we don't have to make gdb
>> non-blocking?
> 
> Maybe yes, because I would expect a GUI be primed with all those bits
> anyway, for the sake of displaying them graphically rather than textually.
> E.g., to display the breakpoint list as something other than raw "info
> breakpoints" output, a GUI would need to know about breakpoint numbers,
> conditions, commands, threads, etc.
>

I think I was making the distinction between having data structures to
represent all these sorts of things, which the GUI probably will need, and
actually prospectively filling them all before certain classes of operation,
because the GUI knows the user might open a new window requiring their data,
and GDB will be unresponsive during the given operation, so it can't provide
the info...
 
> Thanks for the in-depth response,
> 

Interesting discussion, no prob...

Jim