Have tests reflect that OpenBLAS + OpenMP on Windows can in theory have correct thread-local behavior

[itamarst]

Once #228 is merged, when OpenBLAS is compiled with OpenMP, OpenMP APIs are used to set the number of threads, since that has the desirable thread-local scope.

On Windows, however, the behavior of omp_set_num_threads() is still process-wide, not the desired thread-local scope. So the tests to ensure thread-local behavior don't currently run on Windows.

It's likely that this deficiency is solved by compiling with the /openmp:llvm flag. This flag is documented as experimental (as of September 2026), so it's not clear if it's being used in the real world.

But if it is discovered to be used in the real world, the tests can be updated to run on Windows as well if it can be detected somehow (specific OpenMP symbols? An OpenMP introspection API?) that OpenBLAS was compiled with this flag.

[ogrisel]

I wouldn't mind trying to build a Cython helper as part of our test suite to check that we can detect and check thread-local thread-limit semantics for OpenMP on Windows via this flag.

We could also open an issue on the openblas conda-forge feedstock to ask if such an alternative openblas with OpenMP build (with libomp) would be possible on Windows. That would allows us to more easily test that we can detect the different variants of OpenBLAS with or without thread-local semantics on all platforms and check whether that allows us to mitigate oversubscription problems on numpy, scipy and scikit-learn workloads.

Once we have a better understanding of the pratical benefits and limitations of OpenBLAS+OpenMP combinations, we could also open an RFC issue on https://github.com/MacPython/openblas-libs to discuss the possibility of changing the threading layer of the OpenBLAS vendored in numpy and scipy.