[ENH] Support for the nogil branch of Python

[vyasr]

Is your feature request related to a problem? Please describe.

Since PEP 703 has been accepted, has Cython discussed plans for supporting this mode, either when it drops (presumably in 3.13) or in a later release when it becomes the default (probably much later, I haven't fully kept up with discussions but I think that's expected to be a multi-release change)? Based on the various discussions on the threads about the GIL removal, it seems like many extension modules using Python's public C API should be able to transition to using nogil without too much pain as long as they aren't implicitly relying on the locking in their own internal logic independent of Python's APIs. However, given Cython's extensive usage of Python internals, I suspect that many Python functions that Cython relies on may not be made thread-safe in a public release of nogil, so Cython's internals will require a fair bit of work to test here. Is that a fair assumption?

I have no immediate need for this feature, but I have heard the question come up in a few discussions now so I thought it would be helpful to start a public thread. Presumably Cython wouldn't want to touch this until after the 3.1 release removes all the legacy 2.7-3.6 code paths anyway. Apologies if this question has already been asked elsewhere, I haven't been able to find any discussion of it on the issues or in the cython-users mailing list.

[scoder]

Support is mostly there in the master branch (3.1) and we're discussing some more fixes in pull requests currently.

[leofang]

Q: As a Cython user, is there anything I should do/change to support the nogil Python? Are they any change needed in the Cython code or build system (ex: compiler/linker flags, compile-time macros, ...)? It would be great to have a single page in the docs for reference.

[da-woods]

Q: As a Cython user, is there anything I should do/change to support the nogil Python? Are they any change needed in the Cython code or build system (ex: compiler/linker flags, compile-time macros, ...)? It would be great to have a single page in the docs for reference.

I don't think you need to do anything special (except for using the Cython master branch rather than a release). Although I haven't tried it myself yet - we've just accepted a few patches from people interested in it.

[scoder]

Q: As a Cython user, is there anything I should do/change to support the nogil Python?

I don't think there are any guidelines on this. We're still in the very early stages. There will probably be rules of thumb once a number of projects have attempted the adaptation and were able to collect some experience with it. But all code is different. Note that extensions will have to opt-in to running without the GIL held. However, this seems to only apply to the module init code, not to the exposed functions/methods. https://peps.python.org/pep-0703/#py-mod-gil-slot Generally speaking, CPython is removing a lock here that previously guarded all sorts of code, state and data structures against race conditions and concurrent modifications. That suggests that a lot of code (probably most code) will now exhibit these issues when run concurrently. I've personally relied on the GIL in several libraries that I've written. Making them run without the GIL will probably require some kind of dedicated locking now to assure correctness. Even worse, this might now have to be done at a per-interpreter level rather than globally, which complicates things further. IMHO, CPython itself should provide some of the tooling that we need now, especially portable, per-interpreter locks, as well as platform independent inline intrinsics for atomic CPU instructions.

[da-woods]

Note that extensions will have to opt-in to running without the GIL held. However, this seems to only apply to the module init code, not to the exposed functions/methods. https://peps.python.org/pep-0703/#py-mod-gil-slot

Right now I don't that that's implemented (python/cpython#116882) so we can't do anything but it will be soon.

My understanding is that if you import a single extension module that says that it needs the GIL then the interpreter will re-enable the GIL at runtime until it shuts down. So I don't think it's just for the module init function.

I've personally relied on the GIL in several libraries that I've written.

We should probably give users the choice about what to report with that slot. So that people who know they rely on the GIL can report that correctly (even if we believe that Cython generates suitable code).

[FeldrinH]

Generally speaking, CPython is removing a lock here that previously guarded all sorts of code, state and data structures against race conditions and concurrent modifications. That suggests that a lot of code (probably most code) will now exhibit these issues when run concurrently.

In current Cython an established idiom seems to be using a with gil block inside a with nogil block to call a short snippet of Python code and then release the GIL again. In a free-threaded build will this idiom need to be changed? I read that the CPython free-threaded build uses a lot of internal locks inside individual data structures to avoid data races. Will Cython libraries need to do anything special to support this? What will with gil and with nogil do in a free-threaded build? Are they just no-ops?

[da-woods]

In current Cython an established idiom seems to be using a with gil block inside a with nogil block to call a short snippet of Python code and then release the GIL again. In a free-threaded build will this idiom need to be changed?

[...]

What will with gil and with nogil do in a free-threaded build? Are they just no-ops?

Yes - in a free-threaded build with gil and with nogil will just be no-ops. The easiest option (and definitely the short-term plan) would be to keep requiring users to write them.

I read that the CPython free-threaded build uses a lot of internal locks inside individual data structures to avoid data races. Will Cython libraries need to do anything special to support this?

The current status is that you should assume Cython is broken with a free-threaded build and multiple threads acting on Python objects.

Longer-term I think Cython will aim to be thread-safe with respect to reference counting Python objects so that users shouldn't be able to corrupt the interpreter state by default. (Although they can have plenty of logical data-races of their own).

I think it's an open question how far we go with making things like C floats thread-safe. But it's quite likely that they won't be.

Right now, I don't think the free-threading build of Python exposes all the synchronization tools that were promised in the PEP (and that may be needed to make things work well). So it's quite likely that we won't be able to support free-threaded Python 3.13 well, and that users should remember that free-threading is very experimental and adjust their expectations to match that.

[stonebig]

failing at https://cython.readthedocs.io/en/latest/src/tutorial/cython_tutorial.html#fibonacci-fun with windows 11 non-english and python-3..11.0b1 python-3.13t.exe from python.org and pure-wheel from CI of May 16th

[da-woods]

@stonebig I'm temporarily separated from my Windows laptop so can't confirm it easily at the moment. I'll have a look in a week or so when I have access to Windows.

I definitely don't think English/non-English should make any difference. I don't see why Windows would make a difference but it's possible that it might.

Right now the free-threading build is only tested informally by people who are interested in it and it isn't part of the CI so it definitely isn't well-tested.