[Lldb-commits] [lldb] r127438 - /lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp

Caroline Tice ctice at apple.com
Thu Mar 10 16:21:55 PST 2011

Author: ctice
Date: Thu Mar 10 18:21:55 2011
New Revision: 127438

URL: http://llvm.org/viewvc/llvm-project?rev=127438&view=rev

Add some explanatory comments.


Modified: lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp?rev=127438&r1=127437&r2=127438&view=diff
--- lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp (original)
+++ lldb/trunk/source/Interpreter/ScriptInterpreterPython.cpp Thu Mar 10 18:21:55 2011
@@ -1384,6 +1384,17 @@
 	    // The following call drops into the embedded interpreter loop and stays there until the
 	    // user chooses to exit from the Python interpreter.
+        // When in the embedded interpreter, the user can call arbitrary system and Python stuff, which may require
+        // the ability to run multi-threaded stuff, so we need to surround the call the the embedded interpreter with
+        // calls to Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS.
+        // We ALSO need to surround the call to the embedded interpreter with calls to PyGILState_Ensure and 
+        // PyGILState_Release.  This is because this embedded interpreter is being run on a DIFFERENT THREAD than
+        // the thread on which the call to Py_Initialize (and PyEval_InitThreads) was called.  Those initializations 
+        // called PyGILState_Ensure on *that* thread, but it also needs to be called on *this* thread.  Otherwise,
+        // if the user calls Python code that does threading stuff, the interpreter state will be off, and things could
+        // hang (it's happened before).
         PyGILState_STATE gstate = PyGILState_Ensure();

More information about the lldb-commits mailing list