When loading shared libraries, the mechanism on Linux to enumerate shared libraries is the POSIX dl_iterate_phdr API. This takes a callback that is called on every loaded library, and in threadpoolctl this calls back into Python.
The callback then loads the library with dlopen(), and gets some info, which among other thing ends up calling mkl_get_num_threads().
This becomes a problem in the case of mkl with libiomp, perhaps because it does its own dlopen() (loading "libarcher.so") when mkl_get_num_threads() is called leading to some sort of reentrancy.
I haven't figured out exactly how this triggers a deadlock, it requires multiple threads and happens consistently when tests/_limit_blas.py is called in #228 (including if you run that file on master, it's not about any changes I made in the PR).
The solution, to be added to #228, is to minimize the work done in the Python callback so there's no reentrancy into mkl/dl/anything else.
When loading shared libraries, the mechanism on Linux to enumerate shared libraries is the POSIX
dl_iterate_phdrAPI. This takes a callback that is called on every loaded library, and in threadpoolctl this calls back into Python.The callback then loads the library with
dlopen(), and gets some info, which among other thing ends up callingmkl_get_num_threads().This becomes a problem in the case of mkl with libiomp, perhaps because it does its own
dlopen()(loading "libarcher.so") whenmkl_get_num_threads()is called leading to some sort of reentrancy.I haven't figured out exactly how this triggers a deadlock, it requires multiple threads and happens consistently when
tests/_limit_blas.pyis called in #228 (including if you run that file onmaster, it's not about any changes I made in the PR).The solution, to be added to #228, is to minimize the work done in the Python callback so there's no reentrancy into mkl/dl/anything else.