←back to thread

495 points guntars | 1 comments | | HN request time: 0.208s | source
Show context
Seattle3503 ◴[] No.44981374[source]
> For example when submitting a write operation, the memory location of those bytes must not be deallocated or overwritten.

> The io-uring crate doesn’t help much with this. The API doesn’t allow the borrow checker to protect you at compile time, and I don’t see it doing any runtime checks either.

I've seen comments like this before[1], and I get the impression that building a a safe async Rust library around io_uring is actually quite difficult. Which is sort of a bummer.

IIRC Alice from the tokio team also suggested there hasn't been much interest in pushing through these difficulties more recently, as the current performance is "good enough".

[1] https://boats.gitlab.io/blog/post/io-uring/

replies(7): >>44981390 #>>44981469 #>>44981966 #>>44982846 #>>44983850 #>>44983930 #>>44989979 #
jcranmer ◴[] No.44981469[source]
There is, I think, an ownership model that Rust's borrow checker very poorly supports, and for lack of a better name, I've called it hot potato ownership. The basic idea is that you have a buffer which you can give out as ownership in the expectation that the person you gave it to will (eventually) give it back to you. It's a sort of non-lexical borrowing problem, and I very quickly discovered when trying to implement it myself in purely safe Rust that the "giving the buffer back" is just really gnarly to write.
replies(3): >>44981493 #>>44981689 #>>44982450 #
stouset ◴[] No.44981493[source]
Maybe I’m misunderstanding, but why is that not possible with a

    Fn(_: T) -> T
replies(3): >>44981684 #>>44981785 #>>44982627 #
IshKebab ◴[] No.44982627[source]
How is that different to

  Fn(_: &mut T)

?
replies(1): >>44983405 #
Soft ◴[] No.44983405[source]
In the former the caller does not retain access to T until Fn returns.
replies(2): >>44984480 #>>44984586 #
1. IshKebab ◴[] No.44984586[source]
That's true of mutable references too though isn't it? In fact lots of people have suggested they should really have been called "exclusive references", since you can actually mutate some objects through non-exclusive references (called "interior mutability" normally).