On Sat., 16 Nov. 2019, 7:29 am Eric Snow, <ericsnowcurren...@gmail.com> wrote:
> On Thu, Nov 14, 2019 at 4:12 AM Victor Stinner <vstin...@python.org> > wrote: > > Another approach would be to pass a "PyContext*" pointer which > > contains tstate, but also additional fields. But I chose to state with > > a direct "PyThreadState* tstate" to avoid one indirection to every > > tstate access. Currently, tstate seems to be enough for the current > > code base. > > FWIW, I favor this approach as well. As long as it is an opaque type, > a PyContext allows us to be more flexible in adapting to the future. > For now it could even be a simple alias for PyThreadState. > Regardless, I'm not convinced that using a PyContext will have a real > impact on runtime performance. > > Also, we already use "context" in a number of ways in Python. So > "PyContext" might not be the best name. It probably needs to be a > name without "context" in it or one with a concrete clue (e.g. > 'PyRuntimeContext"). > I think we should just stick with "PyThreadState", as that makes it clear that in normal circumstances, it means "the Python State for the currently running Thread". If a function accepting this parameter needs to call back in to Python code, or invokes a function pointer that might call back into the public C API, it's going to need to enforce that assumption by switching the active thread state if necessary. You can already navigate from the thread state to the interpreter state and runtime state, so it should cover everything that we need. Cheers, Nick. >
_______________________________________________ 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/2XQQCEYCYKUFEJMSMO324NC3IOBKEOQ4/ Code of Conduct: http://python.org/psf/codeofconduct/
