-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[Python] Support for the free-threaded build of CPython 3.13 #43536
Comments
This is done by passing an extra flag when building the Cython extension modules. It is needed so that the GIL is not dynamically reenabled when importing `pyarrow.lib`.
@lysnikolaou for adding a free-threaded test build, I suppose we will want to add a wheel build as well (so after #43539 is finally ready), to ensure we have nightly wheels people can test with. |
On it. |
### Rationale for this change This is done by passing an extra flag when building the Cython extension modules. It is needed so that the GIL is not dynamically reenabled when importing `pyarrow.lib`. ### What changes are included in this PR? Changes to CMake so that the extra flag is passed when building Cython extension modules. * GitHub Issue: #43536 Lead-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com> Co-authored-by: Sutou Kouhei <kou@cozmixng.org> Signed-off-by: Sutou Kouhei <kou@clear-code.com>
Issue resolved by pull request 43606 |
@lysnikolaou Could you create a sub issue per sub item? Our release management scripts don't support multiple PRs per issue for now. |
This is fine to keep as the general tracking issue (the release script will just only list this issue in the changelog, which IMO is perfectly fine). It is easier project management to keep track of this in a single issue. |
I agree that this issue should be kept open, since it provides a nice overview of what level of support can be expected. @kou Sure! Should I open subissues for the already open/merged PRs as well or is it okay to just do it in the future? |
If @jorisvandenbossche doesn't like create subissues, I don't ask you to create subissues strongly. (As a committer, I don't want to reopen this issue manually after I merge a PR by our merge script.) FYI: We used an umbrella issue and subissues when we added support for Azure filesystem: #18014 |
At the moment all our merge (closes issues automatically) and release scripts (generation of release notes, cherry picking) expect one issue per PR. This was a requirement for JIRA but now that we are tracking issues on GH I think we can revisit that pattern, we could even avoid some issues and just use PRs for some things but this would require some time to adapt our current scripts. As per this particular issue, the biggest potential problems for the release:
To be honest not really breaking issues for the release but if this is a workflow we want to use (which I think we should) we should adapt our scripts. I am currently on vacation so might take some time responding. |
Already merged PRs point to the "parent" issue on the commit message, this is what is used to link the commits to issues on the release scripts, unless we want to change the commit history (which we are not going to do) it doesn't matter if we open issues for the ones already merged :) BTW, thanks for the great work you are doing @lysnikolaou |
Ok then, I'll be creating subissues for PRs I open from now on. Thanks everyone! |
### Rationale for this change For better reference safety under Python free-threaded builds (i.e. with the GIL removed), we should be using `Py(List|Dict)_GetItemRef` that return strong references and are implemented in a thread-safe manner. ### What changes are included in this PR? - Vendor a copy of https://github.com/python/pythoncapi-compat - Port to strong reference APIs for lists and dicts ### Are these changes tested? I ran the tests with the free-threaded build before and after, and there's the same expected failures. * GitHub Issue: #43536 Lead-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com> Co-authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
Issue resolved by pull request 43540 |
Can we please reopen this? These are PRs that I had created before we discussed this. Sorry! |
Woops, sorry, I've been a bit too optimistic here :) |
#43671) ### Rationale for this change Testing with the free-threaded build is required for adding support for it. (see #43536) ### What changes are included in this PR? - Add a Docker build with the CPython free-threaded build from deadsnakes. - Add a Crossbow job to run said Docker build with Python 3.13t ### Are there any user-facing changes? No. * GitHub Issue: #43536 Lead-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com> Co-authored-by: Antoine Pitrou <antoine@python.org> Co-authored-by: Sutou Kouhei <kou@cozmixng.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
…d build (apache#43671) ### Rationale for this change Testing with the free-threaded build is required for adding support for it. (see apache#43536) ### What changes are included in this PR? - Add a Docker build with the CPython free-threaded build from deadsnakes. - Add a Crossbow job to run said Docker build with Python 3.13t ### Are there any user-facing changes? No. * GitHub Issue: apache#43536 Lead-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com> Co-authored-by: Antoine Pitrou <antoine@python.org> Co-authored-by: Sutou Kouhei <kou@cozmixng.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
#43965) ### Rationale for this change Building free-threaded wheels is necessary to support the free-threaded build. We probably want to upload these wheels as nightlies somewhere as well, so that downstream users can test the free-threading-related changes. ### What changes are included in this PR? - Add necessary configuration to build 3.13 free-threading wheels on `manylinux`. - Do necessary changes to build free-threaded wheels on macOS as well. ### Are these changes tested? I tested the `manylinux` wheel builds. macOS is still untested, since it's not dockerized. ### Are there any user-facing changes? No. Related to #43536. * GitHub Issue: #43964 Lead-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com> Co-authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
Thanks to astral-sh/python-build-standalone#326 , there should be very soon free-threaded builds available on https://github.com/indygreg/python-build-standalone/ . That might be easier than using a PPA and being constrained to Ubuntu. |
@jorisvandenbossche @pitrou is there anything to be done here for 18.0.0? |
@raulcd I don't think so. The wheels are produced fine AFAICT (hopefully they will correctly be uploaded on PyPI as well? :-)). |
Indeed, I think the basics are ready (I also had the question whether the wheels would automatically be uploaded, but @raulcd thought that would be the case). At the moment the linux wheels builds for free-threaded are failing though, but created a separate issue for that: #44355 I will open a follow-up issue for the remaining tasks, so we can close this was as done for 18.0 |
I am closing this as done for 18.0.0. The only sub-task missing is around testing Cython. Please feel free to open a new issue for that if necessary. |
Describe the enhancement requested
Hey all! 👋
I've started looking into adding support for the 3.13 free-threaded build of CPython. This aims to be a tracking issue for all work necessary to support it. A very high-level list of steps is (more details to follow as I investigate more issues):
PyList_GetItem
,PyDict_GetItem
and friends) under the free-threaded buildpyarrow
is a good candidate to test Cython again, since it's got lots of Cython code. Ideally test Cython nightly and also Freethreading thread safety cython/cython#6226.Py_mod_gil
slot (orPyUnstable_Module_SetGIL
/freethreading_compatible
)Hope this all sounds good! Let me know in case there's something that doesn't seem right.
Component(s)
Python
The text was updated successfully, but these errors were encountered: