Hi,
While I clearly see an advantage of passing explicitly ctx to all functions of the C API, I also see that as a burden. I understood that it's not only calls to the C API that should be modified, but basically all C functions of CPython and all C functions of all C extensions, since ctx always comes from the parent. You would have to propagate ctx to every single C function which indirectly calls a function of the C API.
It's not easy to justify this burden for an application which uses a single thread and a single interpreter.
So yeah, if it would be possible to make ctx implicit... that would be better :-)
Note: I would be curious to see allocator functions like PyMem_Malloc() and Py_DecodeLocale()/Py_EncodeLocale() functions "ctx-aware", since it's complex to use properly these functions during the Python initialization.
Victor
Le jeu. 13 sept. 2018 à 02:22, Neil Schemenauer nas-python@arctrix.com a écrit :
On 2018-09-12, Neil Schemenauer wrote:
Personally, I think the correct way to do it is to pass ctx as the first parameter to all C-API functions. If it is not a global, I think you have to pass it. Other schemes are suboptimal and we should do the correct thing.
After talking to Dino a bit, I'm not sure about this now. It sounds like you could use thread-local storage rather than globals. That would be somewhat more limited but would still, in theory, allow what I was hoping for. The bigger issue seems to be allowing a per-interpreter GIL. Eric Snow is working on this with the multi-core (no GIL-sharing) project and it sounds like he thinks API changes should not be needed.
If my understanding is true, that's great news. The prospect of having to pass ctx everywhere inside CPython internals is quite frightening.
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org