Call H5.open on each H5* static constructor about hdf.pinvoke HOT 8 CLOSED

For our high level API we solved it in a similar way. All static constructors check if H5 lib was initialized already. In order to close we did it that way:

AppDomain.CurrentDomain.ProcessExit += (sender, args) =>
                {
                    try {
                        H5.H5close();
                    }
                    catch {}
                };

@gheber Not sure which risk is there when failing to close the lib though?

from hdf.pinvoke.

There's a whole spectrum of risks/issues, which may or may not materialize if the library cannot shutdown properly. In the worst case, file corruption may occur, and in the best case, nothing bad will happen most of the time, but it might mask trivial or nasty bugs in the application. I think your proposal is better than doing nothing. Could we create an event log entry or raise an event if the return code from H5.close is negative? Just as an attempt to get the developer's attention that something fishy might be going on. We could even try to walk the HDF5 error stack (with H5E.walk) to put some clues into the event message body.

from hdf.pinvoke.

I see. I was hoping that most risk was taken from making sure that the files actually get closed. This is what we do in the high level API. For HDF.PInvoke we could warn the user to at least keep track of the files by using try {} finally {} constructs. It is much easier to realize than deterministic shut down behavior of an exiting process.
Don't know for sure but there is a little red light in my head when thinking about Trace.WriteLine() in a shut down situation. But we need to further investigate AppDomain.CurrentDomain.ProcessExit. Basically, it would be more of a "worst case fallback". So I guess we can do whatever we want and be happy if it works - without relying too much on it.

from hdf.pinvoke.

Making sure that all files are getting closed IS the first step. However, when, for example, external links are involved, matters can be more complicated. See the H5Pset_fclose_degree reference.

from hdf.pinvoke.

Just a heads-up, we'll be discussing the necessity of calling H5.[open,close] at this morning's maintainers meeting. Maybe it won't be necessary after all...

from hdf.pinvoke.

But still "our" initialization (resolve native dependencies) should be called before any of the "real" H5-functions...And who knows which function is called first by the user (I'm thinking of the last three or four comments on #28)??

from hdf.pinvoke.

I agree, it's OUR initialization that we have to control. The discussion here was inconclusive. The official line is this: H5open initializes all global variables used by HDF5. The call to it is triggered by any call to the HDF5 library. H5close is triggered at exit and is supposed to release all resources that were not released by application and HDF5 library. I.e., an application doesn't need to call specifically those functions. An application shouldn’t need to call H5[open,close], unless perhaps it’s dynamically loading the library. The "perhaps" is to be read as, Show me a call path where it's failing! I guess, we'll take that as good news (= one less thing to think about) until we find a situation where this breaks down. @DSanchen's point is well taken, it's all about OUR initialization. This can be seen by commenting out the call to H5.open in _AssemblySpecific.cs. On my machine, which has several copies of the HDF5 library floating around, all hell breaks loose, and tests are failing, because it picks up a random hdf5.dll off the street. The problem is NOT that we aren't calling H5.open, but the mechanism which does OUR initialization is not triggered anymore, and we have a #28 scenario all over again.

from hdf.pinvoke.

Then I guess cleaning up remains for the native DLL 😄

from hdf.pinvoke.