Add support for non-seekable files to RandomAccess #58506
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-io |
… break testing reads
| @@ -92,7 +117,7 @@ internal static unsafe void WriteAtOffset(SafeFileHandle handle, ReadOnlySpan<by | |||
| // the function to be used by FileStream for all the same situations. | |||
| int bytesWritten = handle.CanSeek ? | |||
| Interop.Sys.PWrite(handle, bufPtr, GetNumberOfBytesToWrite(buffer.Length), fileOffset) : | |||
| Interop.Sys.Write(handle, bufPtr, GetNumberOfBytesToWrite(buffer.Length)); | |||
| Interop.Sys.Write(handle, bufPtr, buffer.Length); | |||
There was a problem hiding this comment.
@stephentoub I've removed the call to GetNumberOfBytesToWrite which as you know is used only for testing partial writes in DEBUG.
With pipes|sockets, every read operation is blocked until there is some data available. Even if it's a zero byte read to an empty buffer.
I wanted to test the scenario where we write X bytes to the pipe and try to read Y bytes from it, where Y > X and ensure that the read returns X bytes.
With partial writes emulation provided by GetNumberOfBytesToWrite, the read was returning X / 2 bytes (because this is how much we have written). I could perform more reads using exact length, but in reality we usually don't know how many bytes are available in the pipe|socket. I could not read until read returns 0 because when there is no data available, the read is blocked and does not return 0 ;)
There was a problem hiding this comment.
It's trading off testing one thing for another thing. It's not clear to me that's the right trade off, but if you think so, ok.
There was a problem hiding this comment.
Please keep in mind that we are still testing partial writes for seekable files. I just don't think that we can test non-seekable files using the same approach, as they just block the read when there is no data available.
There was a problem hiding this comment.
I just don't think that we can test non-seekable files using the same approach, as they just block the read when there is no data available.
If the write and read are issued concurrently, it should be fine.
I could perform more reads using exact length
That's how reading generally works, issuing repeated reads until all data expected is consumed.
I wanted to test the scenario where we write X bytes to the pipe and try to read Y bytes from it, where Y > X and ensure that the read returns X bytes.
What guarantees it'll return exactly X bytes at the OS level?
|
@adamsitnik It looks like this PR is back in your court with review feedback that still needs to be addressed/resolved. |
|
Why is this being closed? |
fixes #58381