Hacker News Reader

Comment by tene | Hacker News Reader

https://docs.rs/rio/ is a pretty credible attempt at providing a misuse-resistant API for io_uring, both synchronous and async.

There's still some nonzero complexity in using it instead of read/write, but it doesn't seem particularly burdensome to me.

I've got a lot of hope for higher-level misuse-resistant libraries on top of io_uring.

View on HN

Unfortunately rio is unsound (and the maintainer doesn’t seem to care) [1].

It’s also GPL3 which limits its use in many projects.

But I too am hopeful. Just not for rio’s API model specifically.

[1] https://github.com/spacejam/rio/issues/11

This doesn't read to me as "the maintainer doesn't seem to care" so much as they feel that the unsafety is likely an edge case and, in another issue, there's some more discussion around fixing it.

https://github.com/spacejam/rio/issues/12#issuecomment-58375...

`forgetting` is not an edge case. In the context of rust, having an API that invokes unsafe behavior without it being marked unsafe is not acceptable. Keeping ourselves to this rule is what makes the concept of `unsafe` useful because we can rely on the behavior/api-spec of other code.

Failing to ensure correct behavior in the presence of `forget` means that once the program gets complex enough it can blow up in undetermined ways because one piece of code somewhere wasn't aware of a restriction in another piece of code that is potentially very far away.

Failing to isolate this type of unsafety is a pitfall waiting for some future developer to be trapped in.

I've never personally seen or used mem::forget. I'm sure it happens, of course, and I'm in agreement that the API should be unsafe. I'm just saying it's not clear that they "don't care".

How about https://github.com/quininer/io-uring ? It is licensed under either of Apache2/MIT.

Reply on news.ycombinator.com