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. One thing I just remembered - it may simplify your coding to use the H5Idec_ref() routine instead of the interface specific H5*close() routine. Quincey