h5py currently calls H5Eset_auto before every call into libhdf5, to suppress the normal error-printing behaviour (HDF5 errors are turned into Python exceptions instead). For the most part, calling H5Eset_auto once would work - except that each new thread starts with the default error-printing behaviour again. We want things to ‘just work’ with multiple threads as far as practical, so we silence the errors on every HDF5 call, just in case that’s the first one in a new thread.
What we’d really like is a function that can set the default error function for any new threads - maybe called H5Eset_auto_default. Then we could call this once, and avoid a tiny bit of work on each HDF5 function call.
In the mailing list thread 10 years ago, @koziol said they had created an issue for this. Is that issue still open? Is there any prospect of resolving it for HDF5 1.12?
I had similar problem when working on the c++ solution, which is to delegate the choice to the user with h5::mute and h5::unmute, then the systems does exception handling the usual c++ way..
As a result, by default all HDF5 CAPI calls are printed out, and the software writer is responsible explicitly muting/unmuting them with h5::mute | h5::unmute . Because the C++ library is header only, there is no simple way to intialize default setting other than the python version does: calling a function multiple times, or introducing an additional thread local state.
Although the mute | unmute method seems to work fine in C++ world, I am interested in solutions that make life easier without trade offs regarding performance.
h5py similarly has silence_errors and unsilence_errors to disable & enable the HDF5 built in error printing. But it tries to silence them by default, and unsilence_errors has been broken for some time (probably years), because they would effectively be silenced again before each call.
