Author vstinner
Recipients vstinner
Date 2020-05-11.22:23:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1589235805.82.0.0888479979707.issue40601@roundup.psfhosted.org>
In-reply-to
Content
"Statically allocated types" prevents to get per-interpreter GIL: bpo-40512. These types are currently shared by all interpreters.

Eric Snow proposed the idea of creating a heap allocated type in subintepreters. But we should take care of direct usage of the statically allocated type.

For example, Objects/longobject.c defines "PyTypeObject PyLong_Type = {...};". This type is exposed in the limited C API (!) in Include/longobject.c:

PyAPI_DATA(PyTypeObject) PyLong_Type;

It's used but such macro:

#define PyLong_CheckExact(op) Py_IS_TYPE(op, &PyLong_Type)

I don't think that these types are directly accessed in C extensions built with the limited C API. My expectation is that the type is only exposed for "CheckExact" macros.

Currently, 100 statically allocated types are declared in Python header files:

$ grep -F '(PyTypeObject)' Include/ -R
Include/cpython/fileobject.h:PyAPI_DATA(PyTypeObject) PyStdPrinter_Type;
(...)
Include/object.h:PyAPI_DATA(PyTypeObject) PySuper_Type; /* built-in 'super' */
Include/methodobject.h:PyAPI_DATA(PyTypeObject) PyCFunction_Type;

Most of them seem to be exposed in the limited C API.

I propose to break the limited C API backward compatibility on purpose by removing these type definitions form the limited C API.

For "CheckExact" macros, we can continue to provide them in the limited C API but as function calls. So a built C extension would no longer access directly the type, but only do function calls.
History
Date User Action Args
2020-05-11 22:23:25vstinnersetrecipients: + vstinner
2020-05-11 22:23:25vstinnersetmessageid: <1589235805.82.0.0888479979707.issue40601@roundup.psfhosted.org>
2020-05-11 22:23:25vstinnerlinkissue40601 messages
2020-05-11 22:23:25vstinnercreate