Thank you, Dana! Do you think it would be appropriate (not just as of the current implementation, but in terms of the interface contract) to use H5free_memory() on the buffer passed into an H5Z plugin, replacing it with a new (post-compression) buffer allocated via H5allocate()?
On Wed, Nov 8, 2017 at 1:23 PM, Dana Robinson <[email protected]> wrote: > The public H5allocate/resize/free_memory() API calls use the library's > memory allocator to manage memory, if that is what you are looking for. > > > > https://support.hdfgroup.org/HDF5/doc/RM/RM_H5.html > > > > Dana Robinson > > Software Developer > > The HDF Group > > > > From: Hdf-forum <[email protected]> on behalf of Jordan > Henderson <[email protected]> > Reply-To: HDF List <[email protected]> > Date: Wednesday, November 8, 2017 at 12:59 > To: "[email protected]" <[email protected]> > Cc: HDF List <[email protected]> > Subject: Re: [Hdf-forum] Collective IO and filters > > > > Ah yes, I can see what you mean by the difference between the use of these > causing issues between in-tree and out-of-tree plugins. This is particularly > interesting in that it makes sense to allocate the chunk data buffers using > the H5MM_ routines to be compliant with the standards of HDF5 library > development, but causes issues with those plugins which use the raw memory > routines. Conversely, if the chunk buffers were to be allocated using the > raw routines, it would break compatibility with the in-tree filters. Thank > you for bringing this to my attention; I believe I will need to think on > this one, as there are a few different ways of approaching the problem, with > some being more "correct" than others. _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
