Nope, that's how things are designed\. I can imagine that we might want to re\-examine this as we progress into making the library more thread\-friendly, but that might take a while still\. Any suggestions for an alternate design?
The big problem for me is that because my project is a general
interface to Python, I don't have control over thread creation.
Either I demand that my users call a function before using a new
thread, or I call H5Eset_auto before every function call (which is
surprisingly efficient). I could imagine a simple extension of
H5Eset_auto that would do this:
H5Eset_auto(hid_t estack_id, H5E_auto_t func, void* client_data,
where the H5E_scope_t enum has the following values (for example):
H5E_SCOPE_LOCALTHREAD /* set callback for this thread */
H5E_SCOPE_ALLTHREADS /* set callback for all threads simultaneously
(if possible) */
H5E_SCOPE_SETDEFAULT /* make this callback the default for new
threads, instead of printing to stderr */
My desired behavior would be equivalent to H5E_SCOPE_SETDEFAULT, which
would free me from having to call H5Eset_auto everywhere.