Open isuruf opened 1 month ago
@conda-forge-admin rerender
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml
) and found it was in an excellent condition.
To be clear, this is adding the build options for freethreading, not claiming mpl is freethreading safe?
What does "freethreading safe" mean?
To be clear, this is adding the build options for freethreading, not claiming mpl is freethreading safe?
This is building binaries that support the new CPython ABI under the free-threaded build. This is related but orthogonal to supporting free-threading.
You need to explicitly declare that matplotlib's extension modules don't use the GIL to mark matplotlib as thread-safe.
What does "freethreading safe" mean?
Good question! The working definition we've been going with is that you should have similar thread safety guarantees under the GIL-enabled and GIL-disabled build. So any assumptions made in low-level code about the GIL providing locking and making it OK to do things like use C global statics to store module state are no longer OK and all that stuff should be fixed.
However there are lots of other thread safety issues in Python codebases that are unrelated to the GIL, I don't think the presence of any of those issues means a module is "unsafe" under freethreading.
with mpl 3.10.0 we are going to mark our selves as "thread safe", unless this is blocking something maybe wait for that to land on main before re-running this?
or try this on the rc branch.
kiwisolver
is the last hurdle
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)matplotlib has wheels in latest release