Antoine Pitrou added the comment: Le mercredi 29 août 2012 à 02:19 +0000, Nick Coghlan a écrit : > However, it *doesn't* work (at least, not easily) if the extension > itself wants to call back into an interpreter other than the one > already associated with the current thread: > > /* Embedding application (GIL always unlocked) */ > gilstate = PyGILState_EnsureEx(interp_A); > /* Python code and extension code happens */ > /* Callback needs to reach back into a specific interpreter */ > cb_gilstate = PyGILState_EnsureEx(interp_B); > /* Callback runs */ > PyGILState_Release(cb_gilstate); > /* Python code and extension code unwinds */ > PyGILState_Release(gilstate); > > Does that second call to EnsureEx fail?
What would it fail? It should simply change the thread state to interp_B's thread state for the current thread. Then the nested PyGILState_Release changes the thread state back to its old value. (of course, I don't understand how an extension running from a given interpreter would have access to another interpreter's callback, but regardless, it's technically not a problem) > If it succeeds, how does the client know which interpreter to use for > the PyGILState_Release call? It could be made to work if > PyGILState_STATE was changed from an enum to a struct that included in > interpreter state pointer, or if EnsureEx returned a different type > and was paired up with a new ReleaseEx pointer. Making PyGILState_STATE a struct sounds reasonable to me. > However, that's starting to get very messy compared to a separate > SwitchInterpreter call: Why messy? ---------- _______________________________________ 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
