Feature or enhancement
Proposal:
gh-116322 only works for modules using multi-phase init; we need an alternative mechanism for for single-phase init modules since they can't provide m_slots.
We originally considered indicating compatibility in the symbol table of the .so containing the module, either by the presence of a magic symbol, or by providing an alternate init function with a PyInitT_ prefix. As pointed out by @Yhg1s in Discord, that solution doesn't work with modules added to inittab.
The current proposal is:
- Before calling any module init function, enable the GIL if it is disabled (this will most likely be done as part of gh-116322: Add Py_mod_gil module slot #116882).
- In free-threaded builds, add a void *md_gil member to PyModuleObject. It defaults to Py_MOD_GIL_USED (the same constant from Allow C extensions to declare compatibility with free-threading #116322).
- Introduce a new public C API function PyModule_SetGIL(PyObject *mod, void *gil). If a single-phase init module can run without the GIL, it will call PyModule_SetGIL(mod, Py_MOD_GIL_NOT_USED) in its init function. This function will be a no-op in normal builds, and will set md_gil to its argument in free-threaded builds.
- After the init function returns, if the module's md_gil member is set to Py_MOD_GIL_NOT_USED and the GIL was disabled before calling the init function, disable the GIL.
Reactions are currently unavailable
Feature or enhancement
Proposal:
gh-116322 only works for modules using multi-phase init; we need an alternative mechanism for for single-phase init modules since they can't provide m_slots.
We originally considered indicating compatibility in the symbol table of the .so containing the module, either by the presence of a magic symbol, or by providing an alternate init function with a PyInitT_ prefix. As pointed out by @Yhg1s in Discord, that solution doesn't work with modules added to inittab.
The current proposal is: