Hmm....some thoughts... Don't most/all HDF5 calls involve an implicit call to H5open anyways? I mean, code that *never* calls H5open explicitly still works because whenever a function in the library is called, its first action is to effectively call H5open.
I am pretty sure you can call H5open/H5close multiple times without issue. So, why not include an H5open/H5close pair in the "reading function" too? Do you know the "extent" of resources (e.g. how much mem) the HDF5 lib is hanging onto that a call to H5close fixes? I mean, do you really need to call H5close in the saving function? Whats it buying you? Assuming you've got well-behaved code that closes all HDF5 objects (e.g. datasets, groups, attributes, files, etc.) whenever possible, then I don't think there is much else the library itself will hold on to apart from those resources. Probably the free list manager might have some stuff. But, I think you might be able to use H5garbage_collect and/or H5set_free_list_limits (maybe to zero and then back to something reasonable) to explicitly force the lib itself to free those resources making a call to H5Close kinda/sorta unnecessary and redundant. Note that I think H5close *also* shuts down all the HDF5 library apis too. So, they need to be re-started again with a call to H5open. In VisIt, which involves possibly many different HDF5 plugins being used within the same executable, we keep a global count of number of active HDF5 callers. When the count *increases* from zero, we call H5open. When the count *decreases* to zero, we call H5close. But, none of the individual plugins are allowed to call H5open/H5close themselves. I dunno if such a design is an option for you though. Hope some of these ideas help. Mark "Hdf-forum on behalf of Darryl Bryk" wrote: I have a C#.NET app. that writes data to an H5 file. It works correctly except when the data source is another H5 file. In this case the save function must call the reading function to get the file data. Upon return the saving function call to H5G.create to get a group id throws an exception. I think this is because the saving function must call H5.Open before calling the reading function, then the reading function calls H5.Open and H5.Close. Upon return the saving function doesn't have access to the H5 library since it was closed in the reading function. If I take out the call to H5.Close in the reading function, everything works OK, but I wouldn't think this is good policy since you're leaving resources open. Am I doing something wrong here? Any help would be appreciated.
_______________________________________________ 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
