From db567eaca07133a374991153635a119d9eec066b Mon Sep 17 00:00:00 2001 From: David Spickett Date: Wed, 29 Jan 2025 09:58:52 +0000 Subject: [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. --- .../ScriptInterpreter/Python/ScriptInterpreterPython.cpp | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp') diff --git a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp index e78e606..f4efb00 100644 --- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp +++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp @@ -152,12 +152,14 @@ public: 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; -- cgit v1.1