Hard disable Py_LIMITED_API under free-threaded build

python-cffi / cffi

A Foreign Function Interface package for calling C libraries from Python.

https://cffi.readthedocs.io/en/latest/

Other

114 stars 41 forks source link

Hard disable Py_LIMITED_API under free-threaded build #125

Closed nitzmahone closed 3 weeks ago

nitzmahone commented 4 weeks ago

Py_LIMITED_API is not currently supported on the t ABI- it will build successfully, but segfaults. Hard disable for free-threaded Pythons until it's working.
full test suite passes under free-threaded Linux x86_64 as of 3.13.0rc2
update some broken test assumptions around limited API support and eager global GC
add non-artifact CI job for 3.13t

fixes #40 fixes #104

~NB: CI will fail on the new 3.13t job until 3.13.0rc2 is available in manylinux and cibuildwheel updates to include it. 3.13.0rc2 includes a fix for embedded interpreter init from non-main threads, which causes several of the embedding tests to fail.~ (or not, since the Pythons in manylinux images purposely omit libpython, so all the embedding tests are currently being skipped in CI anyway :roll_eyes:)

arigo commented 4 weeks ago

Sorry, you're on your own here. I don't have time for a proper in-depth review, and I don't want to do a half-serious one.

nitzmahone commented 4 weeks ago

@arigo No worries- I'll have @mattclay review before I merge (we wrote part of this together this afternoon anyway just messing around).

In general, is there any area or functionality where you definitely would want an opportunity to review changes, or should we just merge stuff once we're happy with it and it's passing tests?

arigo commented 4 weeks ago

I wish I was still interested in the Python ecosystem enough for the free-threading challenge, but it's just not the case. But feel free to ask and tentatively assign me for reviews on other topics, of course! But as far as I can see, most of the rest that needs to be done is just tweaks for the new version of CPython/setuptools/gcc/whatever.

mattclay commented 3 weeks ago

It's worth mentioning that supporting free-threaded builds does not automatically mean running without the GIL. An extension must also opt-in to running without the GIL [1]. Otherwise the GIL is automatically enabled at runtime when the extension is loaded and a warning is issued:

The global interpreter lock (GIL) has been enabled to load module '_cffi_backend', which has not declared that it can run safely without the GIL. To override this behavior and keep the GIL disabled (at your own risk), run with PYTHON_GIL=0 or -Xgil=0.

[1] https://docs.python.org/3.13/howto/free-threading-extensions.html#single-phase-initialization