fix(python/sedonadb): free-threading-safe Tokio runtime teardown; re-enable cp314t macOS wheels - #1067
Conversation
The free-threaded 3.14 (cp*t) test run deadlocks on macOS/arm64 in the raster suite and never completes, so the job only ever failed at the 150-minute cap. Skip cp*t on both macOS jobs; Linux still builds and tests the free-threaded wheels.
paleolimbot
left a comment
paleolimbot
left a comment
There was a problem hiding this comment.
We do in general want wheels for free-threaded Python and to test them. I am guessing this has to do with a violation of threading constraints somewhere between PyO3, Cython, and GDAL between RasterIO, pyogrio, and possibly system GDAL.
Maybe our function integration testing shouldn't be running on wheel tests / should be moved to a separate Python package?
…ading safety; re-enable cp314t macOS wheel tests
james-willis
changed the title
|
@paleolimbot I went back and tried to build a real fix here. I haven't taken a shot at windows; I don't really have a windows machine |
paleolimbot
left a comment
paleolimbot
left a comment
There was a problem hiding this comment.
Thank you for diagnosing this! I'll leave a note on the issue about static global runtimes and why that happened, but in the meantime this is a definite improvement. One idea about a slightly safer way to go about this if it's easy to do and maybe we can also reduce the number of runtimes we create to minimize these interactions.
…th a janitor trash can
2 participants
The free-threaded (cp*t) macOS wheel test hung because the per-connect Tokio runtime's default
Dropblocking-joins its worker threads while attached to the interpreter, which stalls CPython's stop-the-world under free-threading. The runtime now shuts down in the background on teardown instead, so the free-threaded wheels build and run the full test suite again (the macOSCIBW_SKIPis removed).