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


Could we please step back for a moment and see the big picture before
talking about the details?

It's possible that I'm the only clueless one in town, in which case
please be gentle with me ;-).  But it seems to me that not everybody
in this thread has the same purpose in mind when discussing the
non-blocking features.  So perhaps it will help to revisit the broader
issue, even if it were discussed in the past.

I mean, non-blocking is nice, but where would a user want it in GDB?

To me, a debugger is a way of tightly-controlled program execution.
We all know how much concentration and detail it takes to debug a
non-trivial program.  You need to be sure what is the current state of
the program, before you make the next step.  Finding out the exact
state of the program might require printing lots of variables,
examining registers, calling functions, head-scratching, hair-pulling,
etc.

So what does ``non-blocking'' mean, in this context?  If I ask GDB for
the value of some expression that takes a long time to compute, what
possibly would I want to do while GDB and the inferior grind away to
bring me the result, except wait impatiently for the result to come
through?  I cannot switch to anything else, because that will distract
me, and I will lose my grip on the problem (unless the computation
takes hours, in which case I probably won't use that method of
debugging anyway).

Someone brought up the issue of several targets being debugged
simultaneously.  One possible situation when this will be useful is
when the targets being debugged are parts of a complex system,
i.e. they talk to each other through various means, or act on the same
data.  (Are there any other situations where debugging several targets
simultaneously makes sense?)

If that is the case, would you want to let one target run while the
other is blocked because GDB is interrogating it?  I think not: if you
do, you lose control of what's going on in the larger _system_ you are
debugging.  So, again, there's nothing you can do but wait for the
lengthy operation to complete and show you the results.

Only *after* you have seen these results, can you decide what to do
next.  You could let the program run some more, or add some variables
to the displayed ones and single-step it, or maybe look at some more
variables before you know what to do.  It will not help you to be able
to run the inferior while you are examining variables and thinking
about what you see, because it's quite possible that what the inferior
does while you think will have to be discarded, or even destroys some
data and covers up the traces of the bug you are hunting.  Since
there's no easy way to run the inferior backwards, it's better not to
let it run until you know how do you want to proceed with debugging.

It does make sense to have some degree of non-blocking behavior when
the info I requested is so voluminous that it is larger than I can
grasp in a single glance.  In that case, it is useful to have GDB work
asynchronously while I'm reading the first screenful.  But this kind
of functionality is already supported by the event loop, so if GDB
talks to targets through `select' or `poll', we are done.  This is
nowhere near the problem of GDB and the UI falling out of sync, data
coming to the user that lags behind the inferior program's state,
etc., which, to me, are in sharp contradiction to the very purpose of
debugging: a controlled execution of a program.

In other words, I submit that debugging is a single-thread activity,
as far as we humans are concerned.  And if that is the case, what
exactly do we want the totally-non-blocking GDB for, except the
voluminous output case?

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