Ronald Oussoren <ronaldousso...@mac.com> added the comment:
I'm afraid it will be close to impossible to determine what's going on without
a reproducer.
There's not enough context in the issue to understand the report, in particular
what the main thread is doing and how that's releasing the GIL.
BTW. The code in msg356011 is too complex, it can be simplified to:
// START
class GIL_lock
{
public:
GIL_lock()
{
m_state = PyGILState_Ensure();
}
~GIL_lock()
{
PyGILState_Release(m_state);
}
private:
PyGILState_STATE m_state;
};
// END
This is always safe, even if the thread currently owns the GIL. This will block
when another thread owns the GIL, and will block forever when that other thread
is not running Python code (and will therefore not release the GIL)
Is the problem also present with Python 3.8, or only 3.7?
And for what it is worth, I don't have problems in my own code that uses these
APIs.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue38680>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
