[Lldb-commits] [lldb] db567ea - [lldb][NFC] Format part of ScriptInterpreterPython.cpp

David Spickett via lldb-commits lldb-commits at lists.llvm.org
Wed Jan 29 02:00:58 PST 2025


Author: David Spickett
Date: 2025-01-29T09:59:34Z
New Revision: db567eaca07133a374991153635a119d9eec066b

URL: https://github.com/llvm/llvm-project/commit/db567eaca07133a374991153635a119d9eec066b
DIFF: https://github.com/llvm/llvm-project/commit/db567eaca07133a374991153635a119d9eec066b.diff

LOG: [lldb][NFC] Format part of ScriptInterpreterPython.cpp

Was flagged in https://github.com/llvm/llvm-project/pull/124735
but done separately so it didn't get in the way of that.

Added: 
    

Modified: 
    lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 
    


################################################################################
diff  --git a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index e78e6068debb4f..f4efb00161f8b8 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -152,12 +152,14 @@ struct InitializePythonRAII {
 
 private:
   void InitializeThreadsPrivate() {
-// Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside itself,
-// so there is no way to determine whether the embedded interpreter
-// was already initialized by some external code. `PyEval_ThreadsInitialized`
-// would always return `true` and `PyGILState_Ensure/Release` flow would be
-// executed instead of unlocking GIL with `PyEval_SaveThread`. When
-// an another thread calls `PyGILState_Ensure` it would get stuck in deadlock.
+    // Since Python 3.7 `Py_Initialize` calls `PyEval_InitThreads` inside
+    // itself, so there is no way to determine whether the embedded interpreter
+    // was already initialized by some external code.
+    // `PyEval_ThreadsInitialized` would always return `true` and
+    // `PyGILState_Ensure/Release` flow would be executed instead of unlocking
+    // GIL with `PyEval_SaveThread`. When an another thread calls
+    // `PyGILState_Ensure` it would get stuck in deadlock.
+
     // The only case we should go further and acquire the GIL: it is unlocked.
     if (PyGILState_Check())
       return;


        


More information about the lldb-commits mailing list