-
Notifications
You must be signed in to change notification settings - Fork 18k
proposal: io: io.WriterToAt and io.ReaderFromAt #52383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Can we get the same effect by implementing |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Recently ran into this while attempting to have multiple readers read (via |
Found a more practical way to do this. |
@Jorropo could you share the more practical approach here please, so people tracking or finding this issue can learn the alternative solution? |
Proposal
WriterToAt
ReaderToAt
(exactly the same but reader and writer are swapped)Motivations
Clean (not having to deal with FDs and
CopyFileRange
) concurrent zerocopy.On linux, at least, concurrent reads are writes are perfectly safe and sane as long as no writes overlap and no reads overlap with a write.
Easly composable offset based zero copy.
For example a database that use a single big file could return
*SectionReader
to objects pointing to objects on the disks. And even if multiple step later (after being wrappedio.MultiReader
call for example), zerocopy would still just work.Generalisable, other types like
bytes.Reader
could be optimised that way too.Current
WriterTo
andReaderFrom
allows similar operations if you combine them with seeking andLimitedReader
but that is not concurrent safe.The reason to use
io.Section*
types as wrappers that way is because this avoid an big (8) matrix of required interfaces:With this only 4 interfaces are required. 2 of them are already in the std already.
We replace the type matrix with type assertion in the different implementations.
Related issues:
io.SectionWriter
errors.ErrUnsupported
The text was updated successfully, but these errors were encountered: