NOTE: The 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
netcdf-hdf archives: