[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