[Python-checkins] r50691 - sandbox/trunk/pdb/Doc/lib/libmpdb.tex

matt.fleming python-checkins at python.org
Mon Jul 17 21:57:32 CEST 2006


Author: matt.fleming
Date: Mon Jul 17 21:57:31 2006
New Revision: 50691

Modified:
   sandbox/trunk/pdb/Doc/lib/libmpdb.tex
Log:
Minor changes to the threading documentation.


Modified: sandbox/trunk/pdb/Doc/lib/libmpdb.tex
==============================================================================
--- sandbox/trunk/pdb/Doc/lib/libmpdb.tex	(original)
+++ sandbox/trunk/pdb/Doc/lib/libmpdb.tex	Mon Jul 17 21:57:31 2006
@@ -1030,7 +1030,9 @@
 called \class{_MainThread}. Whenever we refer to the main debugger, this is 
 what we are refering to. The \class{MTracer} objects (slaves) 
 are responsible for tracing threads that are created in the script being
-debugged.
+debugged. Any messages that need to be output to the user are placed
+on the main debugger's \code{outputqueue} queue. This messages are 
+periodically written to the main debugger's \code{stdout} variable.
 
 % How does Python facilitate debugging threads
 \subsection{Python's Thread Debugging Features}
@@ -1083,12 +1085,22 @@
 
 The main debugger is repsonsible for debugging the \class{_MainThread} object
 and the \class{MTracer} objects are responsible for debugging all other
-threads. When a thread needs to stop exection, it acquires the main debugger's
-\member{lock} variable, which is a \class{Lock} object. The \function{acquire}
+threads. When a thread needs to stop exection, it acquires the global lock
+\member{global_lock}, which is a \class{Lock} object. The \function{acquire}
 call will block until the lock is obtained. When this lock is obtained 
 execution transfers to the thread the \class{MTracer} is running in. This
-means that this thread is now the current thread.
+means that this thread is now the current thread. This method of halting
+the execution of the entire program is taken from how GDB handle's threads.
 
+\emph{The GDB thread debugging facility allows you to observe all threads while your program runs--but whenever GDB takes control, one thread in particular is always the focus of debugging.} - \citetitle[http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html\#SEC27]{Debugging with GDB: Debugging programs with multiple threads}
+
+and..
+
+\emph{Whenever your program stops under GDB for any reason, all threads of execution stop, not just the current thread. This allows you to examine the overall state of the program, including switching between threads, without worrying that things may change underfoot.} - \citetitle [http://sources.redhat.com/gdb/current/onlinedocs/gdb_6.html\#SEC45]{Debugging with GDB: Stopping and starting multi-thread programs}
+
+When the main thread exits from debugging, it is system defined as to what
+happens to the other threads. On most systems, they are killed without
+executing \code{try/finally} clauses or executing object destructors.
 
 \section{Remote Debugging}
 \label{remote-debug}


More information about the Python-checkins mailing list