On Mon., 18 Nov. 2019, 8:19 am Nathaniel Smith, <n...@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 >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W3DJG5NTRCQJ45SYGYSJLGWC5AM2Z3W5/ Code of Conduct: http://python.org/psf/codeofconduct/
