You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
std::io::copy contains specialisation for File, by getting the file type and then infer if any optimization (splice/sendfile/copy_file_range) can be applied.
Currently this optimization cannot applied to types outside of stdlib, because does not know if their Read/`Write implementation uses the fd or not.
This is a missing opportunity.
Motivating examples or use cases
For examples, crates might wrap I/O type in stdlib to provide their own abstraction, however these abstractions cannot use the specialisation in std::io::copy and thus would have surprising performance difference from using the underlygin stdlib I/O directly.
It would confuses the users as Rust promises zero-cost abstraction and one would assume there's something wrong with their implementation, causing the performance loss.
Solution sketch
The reason these specialisation cannot be applied to non stdlib-types, is that we cannot guarantee their Read/Write implementation uses the fd returned by AsRawFd.
So if we have new unsafe traits that asserts that the Read
/// Asserts that the Read implementation reads from the fd returned by [`AsRawFd::as_raw_fd`] directly,/// without any processing or bufferingunsafetraitReadFromFd:Read + AsRawFd{}/// Asserts that the Read and BufRead implementation reads from the fd returned by AsRawFd::as_raw_fd directly,/// without any processing but can have buffering.unsafetraitBufReadFromFd:BufRead + AsRawFd + !ReadFromFd{/// Return the internal buffered read.fnget_buffer(&mutself) -> &[u8];}/// Asserts that the Write implementation writes to the fd returned by [`AsRawFd::as_raw_fd`] directly,/// without any processing, but can have buffering if [`Write::flush`]/// flush all of themunsafetraitWriteFromFd:Write + AsRawFd{}
We could go one step further, and add methods for zero-copy:
We discussed this in the libs-api meeting today. We believe that the ability to efficiently copy data from one FD to another is useful, but don't think that this interface is the right way to expose this. Instead we would like to see a unix-specific function that takes 2 BorrowedFds and automatically finds the most efficient way to transfer the contents of one into the other.
Proposal
Problem statement
std::io::copy
contains specialisation forFile
, by getting the file type and then infer if any optimization (splice
/sendfile
/copy_file_range
) can be applied.Currently this optimization cannot applied to types outside of stdlib, because does not know if their
Read
/`Write implementation uses the fd or not.This is a missing opportunity.
Motivating examples or use cases
For examples, crates might wrap I/O type in stdlib to provide their own abstraction, however these abstractions cannot use the specialisation in
std::io::copy
and thus would have surprising performance difference from using the underlygin stdlib I/O directly.It would confuses the users as Rust promises zero-cost abstraction and one would assume there's something wrong with their implementation, causing the performance loss.
Solution sketch
The reason these specialisation cannot be applied to non stdlib-types, is that we cannot guarantee their
Read
/Write
implementation uses the fd returned byAsRawFd
.So if we have new
unsafe
traits that asserts that theRead
We could go one step further, and add methods for zero-copy:
which will help fix rust-lang/rust#128300
Alternatives
Maybe stablise min specialisation and expose more internals of
std::io::copy
?Related
#202
The text was updated successfully, but these errors were encountered: