Nathan Goldbaum

Nope, and upstream CPython isn't planning to either.

For what it's worth, we test with a relatively old limited API version: https://github.com/numpy/numpy/blob/ccff7fb327ed47db2dc94e2015572d4c75ccc9fd/numpy/_core/tests/examples/limited_api/limited_api1.c#L1

In addition to the failure you left a comment for, I also see a different failure which is more obviously a thread safety issue in hypothesis itself: ``` self =...

It's also probably worth adding some tests for sharing a compressor or decompressor between threads. It looks like the GIL does get released when calling into the C zstd library,...

I'm running it all locally on my mac dev machine. I installed the library with `pip install -e .` then ran `ZSTD_SLOW_TESTS=1 pytest --numprocesses=1 --parallel-threads=10 -v tests/test_decompressor_fuzzing.py` after installing the...

You can make it thread-safe if you do something like this to add a per-decompressor lock: https://py-free-threading.github.io/porting/#dealing-with-thread-unsafe-libraries. Of course that won't scale well but as you said it's a weird...

Oh you said it's a bug in the default build I missed that. We've generally been trying to fix pre-existing thread safety issues that can be triggered in the default...

Maybe @andfoy or @lysnikolaou know what's up with the warning.

You could have an atomic flag that a thread sets when it acquires the context, if another thread tries to acquire a context with the flag set then that would...

You can also use PyThread_type_lock on older python versions. It's sadly undocumented in CPython but you can take a look at what I did to make NumPy's use of lapack_lite...