Understood. I was just thinking the H5 library should operate "as if" it was an object, like a file, and be "owned" by the caller only, so that this confusion in resources doesn't happen.
My reading function does call open/close. That's the problem. When it returns to the saving function its no longer opened so the call to H5G.Create fails, and the group id needs to be setup again. The saving function works properly if I don't call close in the reading function. It will get called in the saving function at the end. But then when I use the reading function by itself (only needing to read, not save) then H5 doesn't get closed.
I'm thinking that putting my H5 calls into a class with non-static methods may solve this problem.
···
________________________________
From: Hdf-forum <hdf-forum-bounces@lists.hdfgroup.org> on behalf of Miller, Mark C. <miller86@llnl.gov>
Sent: Thursday, January 26, 2017 1:46 PM
To: HDF Users Discussion List
Subject: Re: [Hdf-forum] H5.Close causing problems
Well, be careful here. You're orig. message was talking about the non-F-qualified functions H5open/H5close. Those are for the *whole* library and are not specific to any file -- though they will result in closing all open objects which would include any open datasets, groups, attributes and even files. There are also file-specific H5Fopen/H5Fclose functions thare are specific to a given file. Now, calling H5Fclose will NOT *always* close the file. If you have left any objects in the file open, then H5Fclose will NOT close the file until those objects are closed. See https://support.hdfgroup.org/HDF5/doc/RM/RM_H5P.html#Property-SetFcloseDegree
Mark
"Hdf-forum on behalf of Darryl Bryk" wrote:
Since the reading function is also used by other callers besides the saving function it calls close. So I can't rely on the saving function to close the H5, since its only called when saving.
I would think that access to H5 should be like handling file access. When you open a file in a function it "belongs" to that function only and if another function opens up a file, another handle is accessed independently from the first function. Like a class handles an object. But I guess the library doesn't work this way.
Perhaps this can be solved by putting all my H5 functions into a class, non-static, and when instantiating the class, H5.Open is called, and destroying the class is when close is called. Have to think about this some more.
________________________________
From: Hdf-forum <hdf-forum-bounces@lists.hdfgroup.org> on behalf of Miller, Mark C. <miller86@llnl.gov>
Sent: Thursday, January 26, 2017 12:56 PM
To: HDF Users Discussion List
Subject: Re: [Hdf-forum] H5.Close causing problems
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.
