Eric Snow <ericsnowcurren...@gmail.com> added the comment:
(Sorry for the delay!) Is the need for a named section due to the fact that _PyRuntime is part of the "internal" C-API (hidden behind the Py_BUILD_CORE macro)? I.E. would it help to build with Py_BUILD_CORE? Regarding the GIL: The plan for 3.9 is to have one GIL per interpreter, so the relevant struct would be PyInterpreterState (a part of the public C-API). That would be accessible at runtime via the fields of _PyRuntime.interpreters. Regarding what I said before about multiple runtimes per process: Honestly, I've yet to see any use case that would justify providing multi-runtime support. However, there are code-health benefits to keeping *all* runtime state out of static globals. So eliminating the _PyRuntime static variable is still a realistic possibility (for 3.9 or maybe later). If that happens then there would have to be a new embedding C-API oriented around (opaque) PyRuntimestate pointers. See PEP 432 and 587 for ongoing work to improve the embedding experience (for runtime initialization), including what the successors to Py_Initialize() look like. ---------- versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32280> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
