Hi,
I am using H5Eset_auto to register a custom error callback function.
However, it seems I need to call H5Eset_auto again from each new
thread I create; the callback which prints to stderr is used by
default. Is there any way to avoid doing this?
Thanks,
Andrew Collette
Hi Andrew,
On Nov 23, 2009, at 5:28 PM, Andrew Collette wrote:
Hi,
I am using H5Eset_auto to register a custom error callback function.
However, it seems I need to call H5Eset_auto again from each new
thread I create; the callback which prints to stderr is used by
default. Is there any way to avoid doing this?
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?
Quincey
Hi,
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,
H5E_scope_t scope)
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.
Thanks,
Andrew
Hi Andrew,
On Nov 25, 2009, at 2:00 PM, Andrew Collette wrote:
Hi,
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,
H5E_scope_t scope)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.
Seems like a reasonable idea, I've added an issue for it in our tracker.
Quincey
h5py is still doing the same slightly ugly thing - calling H5Eset_auto(NULL, NULL) before every other HDF5 library call. People are unhappy because this makes it impossible to turn on HDF5’s default error reporting if it’s needed for more in-depth debugging.
Is the issue created all those years ago still in the tracker?
Please bump this request, it’s been 12 years since it’s on the tracker.
