xref #670
I took a quick look, and I'm not wholly sure on what parts of the locking, possibly synchronizing access to the c-bloc library. Worst case scenario, maybe each of the codecs need to be checked for support.
The standard TODOs for adding free-threading support are in two phases, the first of which is a baseline consisting of the following tasks:
The next phase is a bit more invasive, and it involves a single task:
For more details, please see the suggested plan of attack in the py-free-threading guide. The two phase approach is discussed in explosion/cymem#47 (comment) and gorakhargosh/watchdog#1105 (comment).
Note that this is the first time I've looked at this repo, so I might be
missing known issues or code that needs closer inspection. Any suggestions here
will be very useful. I'll start with the build without warning PR as also discussed in #670.
Let me know if I ought to hold off for any reason. (including if @tomwhite is working on it).
xref #670
I took a quick look, and I'm not wholly sure on what parts of the locking, possibly synchronizing access to the c-bloc library. Worst case scenario, maybe each of the codecs need to be checked for support.
The standard TODOs for adding free-threading support are in two phases, the first of which is a baseline consisting of the following tasks:
pytest-run-parallelto find potential issues, and fix them.cp313t-*to CI to build free-threading wheels.The next phase is a bit more invasive, and it involves a single task:
For more details, please see the suggested plan of attack in the py-free-threading guide. The two phase approach is discussed in explosion/cymem#47 (comment) and gorakhargosh/watchdog#1105 (comment).
Note that this is the first time I've looked at this repo, so I might be
missing known issues or code that needs closer inspection. Any suggestions here
will be very useful. I'll start with the build without warning PR as also discussed in #670.
Let me know if I ought to hold off for any reason. (including if @tomwhite is working on it).