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
-
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