Nick Coghlan <ncogh...@gmail.com> added the comment: There's no point improving the multiple interpreter support if it doesn't help applications that are currently broken because of that lack of support.
I believe the patch as currently proposed actually makes things *worse*. With "autoTLSkey" as a static variable, all subinterpreters will use the same key to point into thread local storage (which is defined process-wide). This means they won't tread on each other's toes: the interpreter that creates a thread owns that thread. So Graham's simple use case *should already work*, as the creation of the thread by the subinterpreter will populate autoTLSkey with a valid thread state, which will then be used by calls back in to the GILState API. Looking at 3.2, there appear to be two ways for an application to get itself into trouble: 1. Hand off an OS level thread from the creating interpreter to a different subinterpreter. As far as I can tell, calling GILState_Ensure in such a thread will still acquire the GIL of the creating interpreter (or something equally nonsensical). I may be misreading that though - this isn't exactly the easiest part of the code base to follow :) 2. Native (non-Python) threads will always have their temporary thread state created in the main interpreter unless the application takes steps to precreate a thread state using a different interpreter. So, a new PyGILState_EnsureEx API may be beneficial regardless in order to help with part 2 of the problem, but I think it should be used solely as a way to override "autoInterpreterState". "autoTLSkey" should be left alone so that a given OS level thread can only be owned by one interpreter at a time. Further, there is no need for any function with access to a valid thread state (i.e. _PyGILState_NoteThreadState, as well as PyGILState_Release if autoTLSkey remains a static variable) to take an interpreter argument. These functions can identify the relevant interpreter from the "interp" field of the thread state. TL;DR version: - I agree the compatibility between multiple interpreters and the GILState API can be improved - I agree a PyGILState_EnsureEx that takes an interpreter argument should be part of that solution. - I *disagree* with making autoTLSkey interpreter specific, as it seems to me that will make the situation worse rather than better. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10915> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
