Debugging Multi-threaded Code
Wing's debugger can debug multi-threaded code, as well as single-threaded code. By default, Wing will debug all threads and will stop all threads if a single thread stops. If multiple threads are present in the debug process, the Stack Data tool (and in Wing Pro the Debug Probe and Watch tools) will add a thread selector popup to the stack selector.
Even though Wing tries to stop all threads, some may continue running if they do not enter any Python code. In that case, the thread selector will list the thread as running. It also indicates which thread was the first one to stop.
When moving among threads in a multi-threaded program, the Show Position icon shown in the toolbar during debugging (between the up/down frame icons) is a convenient way to return to the original thread and stopping position.
Whenever debugging threaded code, please note that the debugger's actions may alter the order and duration that threads are run. This is a result of the small added overhead, which may influence timing, and the fact that the debugger communicates with the IDE through a TCP/IP connection.
Selecting Threads to Debug
Currently, the only way to avoid stopping all threads in the debugger is to launch your debug process from outside Wing, import wingdbstub, and use the debugger API's SetDebugThreads() call to specify which threads to debug. All other threads will be entirely ignored. This is documented in Debugging Externally Launched Code and the API is described in Debugger API
An example of this can be seen in the file DebugHttpServer.py that ships with Wing's support for Zope and Plone. To see this, unpack the WingDBG archive found inside the zope directory in your Wing installation.
Note, however, that specifying a subset of threads to debug may cause problems in some cases. For example, if a non-debugged thread starts running and does not return control to any other threads, then Wing's debugger will cease to respond to the IDE and the connection to the debug process will eventually be closed. This is unavoidable as there is no way to preemptively force the debug-enabled threads to run again.