Closed NobodyXu closed 1 month ago
cc @the8472 I think we could fix rust-lang/rust#128300 while also enabling zero-copy on non stdlib types?
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 BorrowedFd
s 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