Message364017
> Why not do so by reverting the change that caused it?
Making PyInterpreterState structure private was motivated by the subinterpreters work but also by the work on cleaning the C API.
Over time, PyInterpreterState became more and more complex because many other structures have been moved there. For example, the GIL, GC state, warnings state, parser state, etc.
I would really avoid exposing the GIL state in the C API since it uses the "pycore_atomic.h" header which caused a *lot* of compiler errors in the past. Most errors were on including the header file, even if the C extension didn't use any atomic variable.
I'm really happy that we managed to move atomic variables into the internal C API: we got less error coming from that. I'm strongly opposed to move PyInterpreterState structure back into the Include/cpython/ C API. That would be a big mistake for various reasons.
Even in CPython, pycore_pystate.h is causing a lot of troubles since PyInterpreterState became very complex. Example in posixmodule.c:
---
#include "Python.h"
#ifdef MS_WINDOWS
/* include <windows.h> early to avoid conflict with pycore_condvar.h:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
FSCTL_GET_REPARSE_POINT is not exported with WIN32_LEAN_AND_MEAN. */
# include <windows.h>
#endif
#include "pycore_ceval.h" /* _PyEval_ReInitThreads() */
#include "pycore_import.h" /* _PyImport_ReInitLock() */
#include "pycore_pystate.h" /* _PyRuntime */
---
pycore_condvar.h is used by the GIL state. |
|
Date |
User |
Action |
Args |
2020-03-12 12:50:44 | vstinner | set | recipients:
+ vstinner, brett.cannon, gregory.p.smith, fabioz, phsilva, dino.viehland, lukasz.langa, Mark.Shannon, eric.snow |
2020-03-12 12:50:44 | vstinner | set | messageid: <1584017444.51.0.230242064678.issue38500@roundup.psfhosted.org> |
2020-03-12 12:50:44 | vstinner | link | issue38500 messages |
2020-03-12 12:50:44 | vstinner | create | |
|