←back to thread

495 points guntars | 2 comments | | HN request time: 0s | 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. andyferris ◴[] No.44984480[source]
I think I'm lost. If I give a mutable reference to a function... I can't access it (even read it) until it returns, no?

What is different?

replies(1): >>44996390 #
2. zbentley ◴[] No.44996390[source]
Let's say a function "foo" calls "fn bar(_: &mut T) -> ()".

When passing a mutable reference, the lifetime of the object is largely decided by "foo" (with some caveats).

Now, let's say that "foo" instead calls "fn bar(_: T) -> T".

When passing the object itself, the lifetime is largely decided/decide-able by "bar".