Replies: 2 comments 1 reply
-
Basically, this seems to be a quirk in h5py and I believe down to HDF5. Given the maturity of HDF5, I believe a flag likely needs to be provided to stop it from reusing the same file descriptor: from h5py import h5f
a = h5f.open(b'a.nc', h5f.ACC_RDONLY)
b = h5f.open(b'a.nc', h5f.ACC_RDONLY)
assert a.fileno == b.fileno |
Beta Was this translation helpful? Give feedback.
1 reply
-
My current inclination, is that our proposed optimizations are attempting to keep references to the datasets alive and thus, HDF5 is trying to keep their cached values alive as a consequence. https://docs.hdfgroup.org/hdf5/develop/group___f_a_p_l.html#ga034a5fc54d9b05296555544d8dd9fe89 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
We are trying to speed up certain operations in
h5netcdf
in h5netcdf/h5netcdf#197One of them seems like it would break the changes introduced in:
#4879
I do not believe the issue is due to h5netcdf, rather to how h5py (and likely HDF5) handles files internally.
I adapted the problematic test, and ran it with h5py version 3.7.0
While the first comparison passes the assertion, the second comparison fails because both values, a and b, are pointing to the new data (increased by 100).
It seems that
h5py
shares the same fileno.Mostly, I find the test a little odd. Is there a flag we should be supplying to h5py to force it to open a new file handle?
Beta Was this translation helpful? Give feedback.
All reactions