Le ven. 24 mai 2019 à 19:29, Steve Dower <steve.dower@python.org> a écrit :
What do you plan to put in such PyContext?
We hadn't figured that out yet, but given that Yury found we needed contextvars because thread locals weren't sufficient after many years, I don't want to assume that the thread state is sufficient.
If we always pass the context struct by pointer, we can even expand its contents without breaking existing code. It just seems like a good engineering design to allow for future growth here.
If we pass a structure by copy, the structure should be copied to every call. It might have a negative impact on performances, especially if the structure contains multiple fields.
If we pass the structure by reference (pointer), it would add yet another indirection to every memory access to the context. It can also have an impact on performance. By the way, my first implementation of _PyBytesWriter was to put everything in a single structure, like OOP. But it was way more inefficient. I had hard time to understand why simply moving pointers into registers made the code way more inefficient. It's something about aliasing... I took some notes there:
https://vstinner.github.io/pybyteswriter.html https://bugs.python.org/issue17742 https://gcc.gnu.org/ml/gcc-help/2013-04/msg00192.html
Since this bad experience, I'm less excited by structures for hot code path :-(
--
In Python 3.7, PyThreadState_GET() is implemented as: _Py_atomic_load_relaxed(&_PyThreadState_Current).
In Python 3.8, it's implemented as _Py_atomic_load_relaxed(&_PyRuntime.gilstate.tstate_current).
_Py_atomic_load_relaxed() should be efficient, but it's called very frequently and it requires memory fences. I expect that not reading an atomic variable by passing directly 'tstate' is more efficient.
Victor
Night gathers, and now my watch begins. It shall not end until my death.