netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ed, > I'm just refactoring some code today, and I note all the code I have > devoted to releasing HDF5 typeids, fileids, groupids, and other ids, > on error conditions. > > This is really all unnecessary work, if I just open the file with the > proper access property list (setting H5F_CLOSE_STRONG), I can cause > the HDF5 library to unwind its own open objects. > > Do we all think it's OK to do that? Is there any reason from the HDF5 > side not to do it? Because it would make my code simpler if I can > count on HDF5 to close everything down, instead of keeping track of it > myself. > > Perhaps an example will illustrate. If a user is reading a > netCDF-4/HDF5 file with the nc_get_var() function, some H5Dread > call(s) take place behind the scenes. If one of these calls fails > (perhaps the file is corrupt), I (of course) return failure, but also > release all HDF5 objects that I've opened/created in order to read > that dataset (typeid, spaceid, etc.) > > Instead, I could leave all these hanging until the user actually > closed the file, and then rely on HDF5 to clean them all up. This > would be helpful because, in general, figuring out all possible things > that can go wrong, and recovering resources is non-trivial. > > On the down-side, any of these hanging resources will accumulate until > the user closes the file. I think that's OK. Anyone > agree/disagree/even care? > > When finally closing the file, I work through all my open HDF5 ids and > close them. But that's just a waste of code too, because why not let > HDF5 do that work? > > Any thoughts would be welcome. I don't recommend this idea, since there's plenty of caching in the HDF5 library and information may be lost if a user's application crashes and there's lots of un-closed IDs lying around. As you point out also, it chews up a lot of memory and other resources. Quincey