This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: non-blocking reads/writes and event loops


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.

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

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

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.

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

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

Thanks for the in-depth response,

Nick

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]