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 <[email protected]> on behalf of Miller, 
Mark C. <[email protected]>
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.


_______________________________________________
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

Reply via email to