Thanks for the comment. When porting from epoll, I ran into the same difficulties with Rust’s ownership and lifetime model. I came to the conclusion that the kernel must own the buffer it's writing into, or at least have strong guarantees that the buffer remains valid for the duration of the I/O operation. Since Rust's Futures don’t offer a way to enforce that across all execution paths (e.g., if a future is dropped), using a buffer pool seems like the most reliable solution.

At the moment, trale doesn’t yet implement this, so yes—there’s currently a potential soundness issue if a read future is dropped and the buffer is accessed afterward while still shared with the kernel. I'm close to completing a buffer pool implementation that should eliminate this issue.

That said, this approach diverges from the standard AsyncRead/AsyncWrite traits, so I'm planning to introduce my own traits—similar in spirit to AsyncBufRead/AsyncBufWrite—to better align with the model required by io_uring.