H5Eset_auto for all threads?


#1

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


H5Eset_auto for all threads
#2

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


#3

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


#4

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


#5

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?