Unique Little Beings
While few python debuggers support threading, Winpdb may be the first Python debugger to do it right. Winpdb uses a novel approach to handling threads in the context of a debugger. Python threads are unique little beings. Unlike C++, you can’t always break into them (make them stop), since they are not always doing Python code, and may actually be blocked indefinitely in some C++ code. And yet, even more peculiar is the fact that a Python session may exist without any threads of execution at all, for example, think of the python interactive interpreter.
Breaking Into the Debugger
In debugger lingo “breaking into the debugger” means requesting the debuggee to pause for our inspection. In Winpdb this is nothing more than a polite request. Individual threads will break at their leisure, and until they do their state is reported as running. The cool thing about the Winpdb model is that we can still control the debuggee in this half broken state as if it was completely broken.
The second scenario, in which no threads exist at all when the break is requested, is only relevant to embedded debugging. In that case we can do very little until the first thread shows up on the radar and the debugger finally really breaks.
Threads of the thread module
There are three kinds of threads in Python. The main thread, threads created through the threading module, and threads created via the thread module. The first two types of threads are traced by Winpdb automatically. However threads created via the threads module are born invisible to Winpdb. To make Winpdb trace a thread created with the thread module, add the following line to the thread’s function:
Again, this line is only needed for threads created with thread.start_new_thread() and is ignored for other kind of threads.
t â€“ List active threads or switch to a particular thread.