Add support for setting the locking behavior when opening file

[mgeplf]

• useful when on a shared filesystem that limits the number of locks, and files are only being read

With with fapl.add(HighFive::FileLocking(true, false)); one gets (on linux):

ninja && strace tests/unit/tests_high_five_base  FileAccessProps-FileLocking |& grep flock
[0/2] Re-checking globbed directories...
[2/2] Linking CXX executable tests/unit/tests_high_five_base
flock(3, LOCK_SH|LOCK_NB)               = 0
root@fc7be3f8f615:/ws/build-ubuntu24.04#

and fapl.add(HighFive::FileLocking(false, false));:

root@fc7be3f8f615:/ws/build-ubuntu24.04# ninja && strace tests/unit/tests_high_five_base  FileAccessProps-FileLocking |& grep flock
[0/2] Re-checking globbed directories...
[2/2] Linking CXX executable tests/unit/tests_high_five_base
root@fc7be3f8f615:/ws/build-ubuntu24.04#

[1uc]

Thank you, that looks like a nice feature. You can fix the formatting by running bin/format.sh. (Delete the venv if it complains.)

Do you understand why CI says it's not working? Plus you should be a dev now, so you can run CI. Sorry about the delay.

[mgeplf]

Do you understand why CI says it's not working?

I'll have a look and try and figure it out - I confess to not having looked at the CI on this repo before.

Plus you should be a dev now, so you can run CI. Sorry about the delay.

Neat, thanks. No worries, I'm not in a rush.

[codecov]

Codecov Report

❌ Patch coverage is 93.75000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
include/highfive/bits/h5p_wrapper.hpp	80.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[1uc]

It might be that the lock is held by the process (using the same instance of the shared library HDF5). It would make sense since it's not clear how locking is needed if there's only one HDF5 application running. However, if there's two separate HDF5 applications/processes running they might need locking to prevent corrupting the file.

I'm not sure I'm making sense, so once more: To test that the locking is working we might to open the file in one application, then while that's running open the same file from another process; the second one must fail.

We don't have CI setup to do this. Therefore, given how trivial the code is; and that we'd be testing HDF5 not HighFive, I think it might be okay to test it once in your application. Then if you say it works, we merge it without the test.

[1uc]

We've never added links to HDF5 documentation, because the URLs change almost weekly. Seems like good information though.

[mgeplf]

Would you like me to remove it?

[mgeplf]

It might be that the lock is held by the process (using the same instance of the shared library HDF5).

Yeah, I was hoping to use the behavior that hdf5 has an internal cache, and opening the file in two different modes makes it fail. Unfortunately, this behavior doesn't seem to be true in all cases, hence the failure.

Therefore, given how trivial the code is; and that we'd be testing HDF5 not HighFive, I think it might be okay to test it once in your application. Then if you say it works, we merge it without the test.

Ok, that makes my life easier - I'll remove some of the tests, and see if it runs.

I've tested it locally, I will attach an strace to show the behavior.

Sorry about the delay, been busy - might also be a couple days before I get around to the above.