Le mer. 8 janv. 2020 à 22:15, Nick Coghlan <ncogh...@gmail.com> a écrit :
> The vectorcall convention places a significant emphasis on speed, so
> being able to do a single PyThreadState_Get() call on the initial
> transition from Python to C, and then pass the thread state explicitly
> after that would make a lot of sense.

Honestly, I'm not 100% sure that performance is a good argument in
favor of adding tstate to the calling convention, since we cannot
measure yet the overhead in term of performance of calling frequently
_PyThreadState_GET(), especially with hypothetical changes on the GIL
state API.

I can only "feel" that it might be a performance issue tomorrow.

For me a stronger argument is that it should help to make Python more
"correct" in the case of subinterpreters. Help to get the right state,
since today too many things are "implicit" (rely on "globals").


> So I think this is a good idea, but we might need to place a caveat on
> Python 3.9 that passing in a thread state that is NOT the currently
> active thread state may not work correctly yet (it's going to take a
> while to make sure that we never inadvertently call back into
> "implicit thread state" APIs from the implementation of APIs that
> accept an explicit thread state, and even after CPython itself is
> fixed, there's no telling what other extension modules might be
> doing).

In term of API, we may keep the current *API* unchanged: pass
implicitly the current Python thread state. For example,
_PyObject_Vectorcall() doesn't take a tstate argument, but gets the
current Python thread state.

static inline PyObject *
_PyObject_Vectorcall(PyObject *callable, PyObject *const *args,
                     size_t nargsf, PyObject *kwnames)
{
    PyThreadState *tstate = PyThreadState_GET();
    return _PyObject_VectorcallTstate(tstate, callable,
                                      args, nargsf, kwnames);
}

(I added _PyObject_VectorcallTstate() recently :-))

We can keep this prototype for the public API, but have a *private*
API which allows to pass tstate.

My idea is that internally, tstate would be passed *explicitly*. For example:

res = PyObject_Vectorcall(func, ...); // public API, 3rd party code
vs
res = _PyObject_Vectorcall(tstate, func, ...);  // private API, Python internals

My first question is about the calling convention, not the API ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
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/A35VK4D7DMY5UYSGTWOINHINDY5KM3JV/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to