[Python-Dev] GIL vs thread state (original) (raw)

Guido van Rossum guido@python.org
Mon, 14 Apr 2003 10:10:28 -0400

The docs for PyThreadStateClear() 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 = PyThreadStateSwap(NULL); if (!pts) PyFatalError("wincall (LeavePython): ThreadState is NULL?"); PyThreadStateClear(pts); PyThreadStateDelete(pts); PyEvalReleaseLock(); } 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: PyThreadStateGet: no current thread" in the call to PyThreadStateClear().

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 = PyThreadStateGet(); if (!pts) PyFatalError("wincall (LeavePython): ThreadState is NULL?"); PyThreadStateClear(pts); pts = PyThreadStateSwap(NULL); PyThreadStateDelete(pts); PyEvalReleaseLock(); } 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