And Happy New Year!
while use of pread and pwrite may make some sense, I am just curious if
solution to “…opens HDF5 file read-only, forks, and starts access…” is
to just change order of operations to “…forks, opens HDF5 file read-only
and starts accessing…”?
Personally I can only speculate, but it seems reasonable if operation in
a forked process happens conditionally, depending on other content of
HDF5 file. In this case, re-opening file may inflict performance penalty
and sub-optimal caching. Theoretically, forking should be faster on
Hopefully, original h5py issue submitter chimes in!
I mean, why is it so important to have HDF5 file
handle maintain consistency across forks when underlying standard
interfaces (fopen/fread/frwrite/fclose or open/read/write/close) don’t
do that either?
You are right that
read is a standard interface but
a standard interface as well HDF5 could use the latter to inherit
its good properties.
Do we know if there are any performance implications of
pread/pwrite vs. read/write? Do we know if most implementations of
pread/pwrite just turn around and use read/write? It seems like reducing
from 2 system calls (e.g. seek followed by read) to one (pread) would be
a performance benefit. But, I honestly don’t know.
I believe it wouldn’t be any slower, only a bit less portable.