On Mon., 18 Nov. 2019, 8:19 am Nathaniel Smith, <njs@pobox.com> wrote:
- Eventually make it easier for embedding applications to control which Python code runs in which thread state by moving the thread state activation dance out of the application and into the CPython shared library
That seems like a good goal, but I don't understand how it's related to passing threadstate explicitly as a function argument. If the plan is to move towards passing threadstates both implicitly AND explicitly everywhere, that seems like it would make things more error-prone, not less, because the two states could get out of sync. Could you elaborate?
What I said my original reply: if an API that accepts an explicit thread state ever calls an API that expects an implicit one, we'll need to internally implement the dance to activate the supplied thread state before making that call. At the moment, we expect callers of the public API to do that dance, and it's tricky to get it right in all cases. My hope (and it's a subjective hope, not an objective fact) is that implementing the dance more often ourselves will help us identify future abstractions that will make the public API easier to use correctly in multi-threaded applications. Cheers, Nick.
-n
-- Nathaniel J. Smith -- https://vorpus.org