> The docs for PyThreadState_Clear() state that the interpreter lock must
> be held.
>
> I had this code in ctypes to delete the thread state and release the lock:
>
> static void LeavePython(char *msg)
> {
> PyThreadState *pts = PyThreadState_Swap(NULL);
> if (!pts)
> Py_FatalError("wincall (LeavePython): ThreadState is NULL?");
> PyThreadState_Clear(pts);
> PyThreadState_Delete(pts);
> PyEval_ReleaseLock();
> }
>
> and (under certain coditions, when ptr->frame was not NULL), got
What is ptr->frame? A typo for pts->frame?
If pts->frame is not NULL, I'd expect a warning from
PyThreadState_Clear(): "PyThreadState_Clear: warning: thread still has
a frame\n".
> "Fatal Python error: PyThreadState_Get: no current thread" in the call
> to PyThreadState_Clear().
That's strange, because I cannot trace the code in there to such a
call. (Unless it is in a destructor. Can you tell more about where
the PyThreadState_Get() call was?)
> The GIL is held while this code is executed, although there is no thread
> state. Changing the code to the following fixes the problem, it seems
> holding the GIL is not enough:
>
> static void LeavePython(char *msg)
> {
> PyThreadState *pts = PyThreadState_Get();
> if (!pts)
> Py_FatalError("wincall (LeavePython): ThreadState is NULL?");
> PyThreadState_Clear(pts);
> pts = PyThreadState_Swap(NULL);
> PyThreadState_Delete(pts);
> PyEval_ReleaseLock();
> }
>
> Is this a documentation problem, or a misunderstanding on my side?
> And, while we're on it, does the second version look ok?
>
> Thomas
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4