homepage

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?