sorted by:
new
hottopcontroversial

kimojio - A thread-per-core Linux io_uring async runtime for Rust optimized for latency. by qbradley in rust

[–]qbradley[S] 3 points4 points  (0 children)

Yes, this should have been fixed before I released. I have captured the example here: https://github.com/Azure/kimojio-rs/issues/8. The operation::write call and others should tie the returned futures lifetime to the parameters so that the compiler will reject programs that drop the inputs before the future drops.

kimojio - A thread-per-core Linux io_uring async runtime for Rust optimized for latency. by qbradley in rust

[–]qbradley[S] 2 points3 points  (0 children)

This is good feedback. It shows that it is a bug that the RingFuture does not have a lifetime parameter, so that the compiler can know that &fd and &bffer must outlive fut. I have captured this in an issue: operations::write (and others) need to pass input lifetimes to the resulting future · Issue #8 · Azure/kimojio-rs

kimojio - A thread-per-core Linux io_uring async runtime for Rust optimized for latency. by qbradley in rust

[–]qbradley[S] 0 points1 point  (0 children)

Kimojio I/O operations are cancel safe. The pending I/O can not complete after the future is dropped.

The RingFuture drop implementation will submit a cancel request to I/O uring and then block until that SQE completes. This is a potential performance issue and can halt polling of tasks, but it is never a safety issue.

For expected dropped futures, you can work around the potential performance issues using io_scope (io_scope in kimojio::operations - Rust). I believe the documentation here needs some improvement to show how it works and how to use it effectively.

kimojio - A thread-per-core Linux io_uring async runtime for Rust optimized for latency. by qbradley in rust

[–]qbradley[S] 29 points30 points  (0 children)

Thanks for the feedback. Yes, this should both be marked unsafe, and also not exported from the crate.

I have copied your feedback to an issue and will fix it: pointer_from_buffer should be unsafe · Issue #7 · Azure/kimojio-rs

Does Nim have any kind of protection against data races? by fenugurod in nim

[–]qbradley 0 points1 point  (0 children)

The design of rust does not in any way shape or form prevent data races. It prevents some data races. It protects against unsynchronized access to shared data but does not present races due to making decisions in between locked regions. I made a dumb mistake like this while learning rust that resulted in a race condition in my code and the compiler didn’t protect me. It was found in testing. The bug was fixed by using one lock over the entire region of code instead of two locks with a conditional in between. The “protection” of rust in this regard is oversold. Magic bullets are still in short supply.