Hopefully this results in less work for the HDF5 library (which would
not be done in parallel) and ensures the conversion is consistent
across all data retrieval strategies.
The HDF5 library was made thread-safe via excessive locking, so does
not gain much from reads being parallelized.
By using the H5DOread_chunk function (introduced in HDF5 1.10.2)
we reduce the time spent the library, improving performance for
when XDS uses multiple threads to process data.
The decompression and type conversions have to be done manually
however, and this is only used in a limited case.
Removes all "//" style comments, adds a missing typedef
for "int16_t" (although these are not checked for correct width)
and removes duplicated "intX_t" typedefs.
It would be preferable to detect GCC (with its extensions) and use
its definitions of fixed-with integers if not compiling with C99.
Source for the bitshuffle code is:
https://github.com/kiyo-masui/bitshuffle
Release Tag: 0.3.4
Commit at time of copy:
9ffba9de83036a91d345fa2f62fcaedf55f54c5f
The LZF and HDF5 plugin parts are not included as they are
not required.
This helps prevent potential segfaults due to null-pointer
dereferencing in the face of errors when the plugin is accessed via
multiple threads.
If multiple threads are pushing errors onto the error stack then its
possible for elements of the various string pointer arrays to be left
NULL, causing a segfault when the stack is printed.
Whilst this does nothing to address the "correctness" of the plugin in
a multi-threaded context, at least it shouldn't crash.
Error messages may still be corrupted.
This will cause XDS to segfault on exit, since the plugin (and hence
HDF5 library) will likely have been unloaded.
Calling "H5dont_atexit" before any other H5 calls will prevent the
hook being installed, and we call "H5Close" ourselves as part of the
plugin_close function.
Error messages and function names/line numbers are traced via
__func__ or __FUNCTION__, __LINE__, etc (or just "unknown" if
not available). A manual stack is kept onto which these values
are pushed which can then be dumped to stderr/stdout.
stderr is used to report this information since no other
facility appears to be provided.
The get_frame code always assumed a dataset rank of three, so this
doesn't actually change much, but its one less dynamically allocated
buffer to keep track of.
Charles Mita