-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] Support for the nogil branch of Python #6162
Comments
Support is mostly there in the master branch (3.1) and we're discussing some more fixes in pull requests currently.
|
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. |
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.
|
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.
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). |
In current Cython an established idiom seems to be using a |
Yes - in a free-threaded build
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. |
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 |
@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. |
@stonebig you're right that it crashes on Windows. What's happening is that it's actually compiling a non-free-threaded extension module (which is incompatible). You need to edit pyconfig.h and uncomment the line (or define it in your setup.py file)
However - that still doesn't work because you then get the link error:
The Python binary installer doesn't include this file so at this stage I'm stuck! It's also bad that None of this is a Cython bug so I suggest reporting it to the people who make the Python installers. This is obviously the first one they've done that includes the free-threading build so I guess there's still a bit to learn. For now I've asked on https://discuss.python.org/t/windows-installer-freethreading-and-building-extension-modules/54391 so that's probably a better place to follow it up. |
thank you for having taken the time to check, it could have been a test procedure error from me. |
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.
The text was updated successfully, but these errors were encountered: