Add Lwt_unix.pread and pwrite
#768
Conversation
As stated in https://stackoverflow.com/questions/30278873/is-the-overlapped-structure-updated-when-using-readfile the position in the file is updated contrary to what Microsoft documentation states https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile#synchronization-and-file-position
There was a problem hiding this comment.
Thanks!
Otherwise, I don't know whether the test suite triggers both the job and standard version of the functions. If it doesn't, how should I do this ?
There probably isn't a legitimate way to trigger the non-blocking version of these functions. To my knowledge, on both Unix and Windows, all fds that allow positional I/O also do not support non-blocking I/O. The only exception to that may be asynchronous HANDLEs on Windows, but we don't open HANDLEs in asynchronous mode.
You can still force the non-blocking code to run by calling Lwt_unix.set_blocking ~set_flags:false fd false in additional test cases for this. The non-blocking code added in this PR will then run, but the underlying pread (etc.) calls will still block, and it would be a bug in a user's program if it did this.
You can check whether the code is running by either inserting prints or running make coverage and looking at the branches.
cc @tomjridge
|
Thanks @chambart! I agreed with making the functions separate, rather than using an optional argument. |
I just happened to need those function at the same time as #767. Hence, here it is.
I had to document that
pwriteandpreadleaves the current file position undefined because unixpreadand windowsReadFiledon't agree on that. This doesn't seem to be a serious problem. I don't expect anybody to be using both pread and read/write on the same fd.Thanks for maintaining a functional test suite for Windows I would have been too lazy to bother starting a VM to test that !
Otherwise, I don't know whether the test suite triggers both the job and standard version of the functions. If it doesn't, how should I do this ?