Skip to content

Conversation

@H-Plus-Time
Copy link
Contributor

Yet another fork (this time in setup-python), what exactly was it about setup-uv in windows that broke builds?

Verified wheel building run over at https://github.com/H-Plus-Time/arro3/actions/runs/12349504140.

@kylebarron
Copy link
Owner

kylebarron commented Dec 16, 2024

I was hitting this #263. If you find a way to use uv on Windows I'd be happy to use it. Maybe it's an issue with PATH?

@kylebarron
Copy link
Owner

It's also an issue that the buffer protocol is even less sound in Python 3.13t.

See discussion: https://discord.com/channels/1209263839632424990/1310572181138178129/1310572181138178129, https://alexgaynor.net/2022/oct/23/buffers-on-the-edge/, PyO3/pyo3#2824

I'm not sure what to do here. It's very beneficial to have the buffer protocol as an option. So perhaps just document to Python users that it's unsafe to mutate the Python buffer after passing it to rust?

@H-Plus-Time
Copy link
Contributor Author

Yeah - I'm actually having a great deal of difficulty thinking of buffer protocol scenarios where freethreading would be unsound but not GIL-enabled; there's definitely a difference, but the complete lack of immutability guarantees is 99% of the problem (and serialized python execution (the GIL) addresses the remaining 1%).

I think the safety note on into_arrow_array, surfaced prominently should do the trick.

By the sounds of (amongst other parts of that document) https://py-free-threading.github.io/porting/#dealing-with-thread-unsafe-objects and the comments on how numpy is going ahead with this, pathological cases (like resizing an array while it's being read) can just be left as "you're holding it wrong, enjoy the segfault", right up until the first bug report.

@kylebarron
Copy link
Owner

Hmm it looks like I can't trigger the wheel builds on this repo from your PR.

I think the safety note on into_arrow_array, surfaced prominently should do the trick.

Ideally this would also be surfaced to Python to be seen by Python users, but I'm not sure the right level of obtrusiveness for that.

@kylebarron
Copy link
Owner

It would be nice if we didn't have to use a fork of numpy. Do you know if there's progress towards getting that merged?

@H-Plus-Time
Copy link
Contributor Author

Hmm it looks like I can't trigger the wheel builds on this repo from your PR.

Yeah, I noticed that in my own fork, though that seems to be fine now 🤔. It's likely a matter of: jobs can be triggered manually via workflow_dispatch, but not on pull requests (the wheels would need on: pull_request, which might be ok with cancel-in-progress); there doesn't seem to be a non-convoluted way to do manually triggered PR checks.

@H-Plus-Time
Copy link
Contributor Author

Mm, not yet, probably mid-January (given the whole Christmas/NYE period is upon us) - it looks like it's down to a single mutex, probably test reconfiguration too.

Obtrusiveness-wise, I can stick a (concise) spiel in the docstring of Array::frombuffer; I'd be hesitant to log anything at runtime higher than trace or debug level.

@kylebarron
Copy link
Owner

I'm inclined not to merge this until numpy gets a stable release including the free-threading feature

@H-Plus-Time
Copy link
Contributor Author

H-Plus-Time commented Feb 12, 2025

Yep, I'll stick this one (and related) in draft.

@H-Plus-Time H-Plus-Time marked this pull request as draft February 12, 2025 13:44
@kylebarron
Copy link
Owner

Numpy merged its free-threading pr: PyO3/rust-numpy#471 (comment)

@H-Plus-Time
Copy link
Contributor Author

Excellent, hopefully shouldn't be too much longer until that gets a release. I'll re-pin to the tip of main and see if anything strange crops up in the build in the meantime.

@H-Plus-Time
Copy link
Contributor Author

Hrm, blocked by the pyO3 breaking change in 0.23.4 involving the IntoPyObject constraint and Chrono Tz. With the suggested workaround (map(|v| v.fixed_offset()) specifically), seems to compile fine. By the looks of apache/arrow-rs#7173 and associates, everything should pan out roughly around the same time (the numpy release + patch to obviate the fixed_offset workaround)

…ompile without subsequent commit (avoid keeping it though, since it erases timezone info))
@kylebarron
Copy link
Owner

kylebarron commented Feb 23, 2025

Hrm, blocked by the pyO3 breaking change in 0.23.4 involving the IntoPyObject constraint and Chrono Tz.

Can you merge in latest main? It should be fixed (with a temporary fixed offset workaround)

@kylebarron
Copy link
Owner

With #304 it looks like this might actually be unblocked?

@kylebarron kylebarron marked this pull request as ready for review March 25, 2025 17:01
}

#[pymodule]
#[pymodule(gil_used = false)]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this will always be true for the IO module. E.g. I might want to allow a Python HTTP library like aiohttp to be used for making the parquet file reads

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, if unmodified (as in, rust locking structures cfg-gated on Py_GIL_DISABLED) - there isn't code that allows that quite yet, right?

I should definitely take a crack at pytest-freethread in general before this is merged (at the very least CI for a single test in pyo3-arrow or core).

Thinking about it, pretty much all users of the freethreading build at the moment are other library maintainers porting their package to freethreading - this is probably a rare instance (especially given the main dependant is geoarrow.rust.io) where hard concurrency errors are preferred over RuntimeWarning .

@H-Plus-Time
Copy link
Contributor Author

H-Plus-Time commented Mar 25, 2025

With #304 it looks like this might actually be unblocked?

Oh, excellent - I gather the obstore py03 0.24.0 + object store 0.11 release unblocks this too (via #304 probably), right? That was my last blocker on this (the parquet crate's dependency on object store was involved in there somewhere).

Thought I'd have to wait for the April parquet release.

@kylebarron
Copy link
Owner

@bschoenmaeckers
Copy link
Contributor

bschoenmaeckers commented Jul 3, 2025

I can take a closer look if anything is still depending on the GIL if you want.

there are some functions that take in a py: Python token, and so those presumably would change this.

FYI, Using the Python token does not mean that a function is GIL dependent. It means it requires the python thread state to be initialised.

pyproject.toml Outdated
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.11"
requires-python = ">=3.13"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be reverted before merging.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The top-level pyproject.toml is only for development. This change only means that to run the tests you need to be using 3.13+.

I renamed this name to "dev-environment" to make that clearer.

Regardless, might not need to pin 3.13 here.

@kylebarron kylebarron changed the title Freethreading - module markers + CI feat(arro3): Freethreading - module markers + CI Sep 9, 2025
@github-actions github-actions bot added the feat label Sep 9, 2025
@kylebarron
Copy link
Owner

According to pytest-freethreaded it's also important to run with pytest --require-gil-disabled

When I run this locally with the GIL disabled I get a segfault, so something is wrong? @bschoenmaeckers do you have an idea?

> uv run --python 3.13t pytest --require-gil-disabled
==================================================================== test session starts ====================================================================
platform darwin -- Python 3.13.6, pytest-8.4.2, pluggy-1.6.0
rootdir: /Users/kyle/github/kylebarron/arro3
configfile: pyproject.toml
plugins: freethreaded-0.1.0
collecting ... Fatal Python error: Segmentation fault

Current thread 0x00000002043560c0 (most recent call first):
  File "<frozen importlib._bootstrap>", line 488 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 1320 in create_module
  File "<frozen importlib._bootstrap>", line 813 in module_from_spec
  File "<frozen importlib._bootstrap>", line 921 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1331 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1360 in _find_and_load
  File "/Users/kyle/github/kylebarron/arro3/arro3-compute/python/arro3/compute/__init__.py", line 2 in <module>
  File "<frozen importlib._bootstrap>", line 488 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 1026 in exec_module
  File "<frozen importlib._bootstrap>", line 935 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1331 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1360 in _find_and_load
  File "/Users/kyle/github/kylebarron/arro3/tests/compute/test_aggregate.py", line 3 in <module>
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/assertion/rewrite.py", line 186 in exec_module
  File "<frozen importlib._bootstrap>", line 935 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1331 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1360 in _find_and_load
  File "<frozen importlib._bootstrap>", line 1387 in _gcd_import
  File "/Users/kyle/.local/share/uv/python/cpython-3.13.6+freethreaded-macos-aarch64-none/lib/python3.13t/importlib/__init__.py", line 88 in import_module
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/pathlib.py", line 587 in import_path
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/python.py", line 498 in importtestmodule
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/python.py", line 551 in _getobj
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/python.py", line 280 in obj
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/python.py", line 567 in _register_setup_module_fixture
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/python.py", line 554 in collect
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/runner.py", line 389 in collect
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/runner.py", line 344 in from_call
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/runner.py", line 391 in pytest_make_collect_report
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_callers.py", line 121 in _multicall
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_manager.py", line 120 in _hookexec
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_hooks.py", line 512 in __call__
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/runner.py", line 567 in collect_one_node
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 839 in _collect_one_node
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 974 in genitems
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 979 in genitems
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 979 in genitems
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 979 in genitems
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 813 in perform_collect
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 353 in pytest_collection
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_callers.py", line 121 in _multicall
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_manager.py", line 120 in _hookexec
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_hooks.py", line 512 in __call__
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 342 in _main
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 289 in wrap_session
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/main.py", line 336 in pytest_cmdline_main
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_callers.py", line 121 in _multicall
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_manager.py", line 120 in _hookexec
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/pluggy/_hooks.py", line 512 in __call__
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/config/__init__.py", line 175 in main
  File "/Users/kyle/github/kylebarron/arro3/.venv/lib/python3.13t/site-packages/_pytest/config/__init__.py", line 201 in console_main
  File "/Users/kyle/github/kylebarron/arro3/.venv/bin/pytest", line 10 in <module>

@kylebarron
Copy link
Owner

Now I'm able to reproduce the segfault on CI as well https://github.com/kylebarron/arro3/actions/runs/17590097733/job/49968516771?pr=275

cc @H-Plus-Time as well

@bschoenmaeckers
Copy link
Contributor

I’m not entirely sure what happens here without a debug build of python. Does this error also occur on 3.14?

@kylebarron
Copy link
Owner

Does this error also occur on 3.14?

I tried

uv run --python 3.14t pytest --require-gil-disabled

But that doesn't work out of the box because pyarrow doesn't have a built wheel for 3.14t and I don't want to figure out how to build it. We could split out the tests to not require pyarrow but I don't have time to do that now.

@kylebarron
Copy link
Owner

I updated package versions (esp maturin) and now CI seems to pass 🤷‍♂️.

Thanks all for your work here!

@kylebarron kylebarron merged commit 5c3d865 into kylebarron:main Oct 3, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants