Re: [Bashdb-pydb] Some possible thread debug additions

[Leonid G. <ig...@ho...>]

First of all I want to express my appreciations of efforts that Pydb develo=
pers spent to bring such a superior alternative to the Pdb debugger.=20
=20
Second, a little disclaimer. I have a rather insignificant expertise in Pyt=
hon development in general and system Python programming in particular. My =
background in emacs, bdb, ddd and other UNIX/Linux technologies is also min=
uscule =96 although I have plenty of experience developing multi-threaded a=
pplication via C++ under Windows. Also my mail represents my own day-to-day=
 tactics of tackling variety of debugging issues, which may not be a typica=
l approach for other Python developers.
=20
1.    My bread-and-butter debugging scenario in multithreaded environment i=
s to debug rather small set of source lines at one time. I am typically set=
 few breakpoints in the code executed in thread of my interest and using st=
ep and next (or something like that) to go through my sources examining val=
ue of variables and looking close to code workflow. For that scenario I wou=
ld be definitely interested that step, next, finish and return would be con=
ducted ONLY in the context of current thread. To me continue statement is b=
it different. I would allow it to continue execution of all threads until a=
 BP hit in any of them. The other approach is to allow only current or spec=
ified thread to be continue implicitly should pause other threads execution=
 and while it may be technically feasible on Python it may not be desirable=
 in most of the cases =96 at least for me (one may argue to modify your sug=
gesting to use something like continue __all__ statement)
2.    Sometimes (although not as often as in first scenario) I do like to l=
ook at all or some other thread state (use something like =93info thread=94=
 statement). Typically I would need to do it to understand overall state of=
 execution, debugging for possible deadlocks, or understand dynamics of thr=
eads execution. One can also use this opportunity to move-on on debugging c=
ode executed in the different thread. If new code of interest has no breakp=
oints yet it often useful to put them there at this time and continue (see =
my comment above about continue statement) because quite often the current =
top os stack frame of the other thread(s) locate far apart from the debuggi=
ng area. Only in case if it is right near than your suggestion about next, =
step with thread=92s name/number would be very convenient. One may also sug=
gest to add a =93finish=94 statement to this list. Better yet provide =93fi=
nish=94 with additional optional numerical argument which would allow to fi=
nish more than one function at the time. One my add the same argument to =
=93next=94 statement and even =93step=94 although it probably will be less =
useful than finish.
3.    I would be interested to setup breakpoints only in particular thread =
using its name/number via some optional parameters for cases when you have =
few breakpoints in the code which executed simultaneously by many thread bu=
t you want to follow only one logical/physical thread. Or may be even have =
command which can modify BP to stick only to one, few or all threads. May b=
e this can be done using condition statement but I am not aware how.
4.    I would be interesting to have a statement which can specify to conti=
nue until the following line. One can probably do this with combination of =
tbreak and continue but that would be one statement less to type. Probably =
this can be achieved with alias and I need to run more experiments with thi=
s.
=20
=20
And last but not least, I would like to ask the question which may be sligh=
tly off topic. I would like to examine values via tool-tip if mouse hover o=
ver expression/selection for few seconds, set/remove/disable/display breakp=
oints on the same small vertical grey area where current execution triangle=
 cursor is displayed. I would even move to appropriate code location if dou=
ble-clicked on the stack frame. Or having split gud-xxx window which would =
constantly display =93display=94 values, list of break points and let=92s s=
ay list of threads. It probably can be done mostly in LISP and no one would=
 spent an effort but who said that we cannot dream J
=20
Thank you guys.
=20
Len.
=20
=20
=20
_________________________________________________________________
Share your special moments by uploading 500 photos per month to Windows Liv=
e Spaces=20
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=3Dhttp://=
www.get.live.com/spaces/features=