Nick Coghlan added the comment:
No, those wouldn't change at all. However, after thinking about it further, I'm
leaning back towards the option of an EnsureEx/ReleaseEx pair that allows the
previous interpreter to be reported and restored along with the GIL state. I'd
also like to make the state an opaque structure that isn't exposed in the
limited API. Something along the lines of:
typedef struct _gilinfo {
PyGILState_STATE lock_state;
PyInterpreter *active;
} PyGILState_INFO;
int /* Allow returning an error code */
PyGILState_EnsureEx(PyInterpreterState *target,
PyGILState_INFO *prev);
void
PyGILState_ReleaseEx(PyGILState_INFO *prev);
This allows various issues related to implicitly creating thread states to be
handled the same way they are now, where PyThreadState_New will create a
persistent thread state, while PyGILState_EnsureEx will either use a
preexisting thread state for the requested interpreter (if it exists), or
implicitly create one. Implicitly created thread states would be destroyed by
the corresponding call to ReleaseEx.
To make this work, I believe all that should be needed is for:
1. PyInterpreterState updated to include a per-interpreter TLS key
2. _PyGILState_NoteThreadState would update both the autoTLSkey entry and the
per-interpreter key entry
3. PyGILState_EnsureEx added to support switching the autoTLSkey entry to point
to a different thread state (creating it if needed)
4. PyGILState_Ensure updated to map to PyGILState_EnsureEx(NULL) and to extract
the lock state from the info structure
5. PyGILState_Release updated to populate the info structure with the active
interpreter and the passed in previous GIL state before calling
PyGILState_ReleaseEx
5. PyThreadState_Delete and PyThreadState_DeleteCurrent updated to also clobber
the per-interpreter TLS key entry
PyThreadState_New already calls _PyGILState_NoteThreadState implicitly, so
Python created threads (and embedded threads with an explicitly created thread
state) should do the right thing automatically.
Making the INFO struct an opaque token also means it can be expanded to cover
any future needs that arise.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15751>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
