tokio-uring

A tokio-uring backed runtime for Rust (by tokio-rs)

Stats

Basic tokio-uring repo stats
9
3
0.0
5 days ago

tokio-rs/tokio-uring is an open source project licensed under MIT License which is an OSI approved license.

Tokio-uring Alternatives

Similar projects and alternatives to tokio-uring
  • GitHub repo rust-analyzer

    A Rust compiler front-end for IDEs

  • GitHub repo rust

    Empowering everyone to build reliable and efficient software.

  • GitHub repo coc.nvim

    Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers.

  • GitHub repo Rustlings

    :crab: Small exercises to get you used to reading and writing Rust code!

  • GitHub repo tokio

    A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...

  • GitHub repo sqlx

    🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, SQLite, and MSSQL. (by launchbadge)

  • GitHub repo rust.vim

    Vim configuration for Rust.

  • GitHub repo liburing

  • GitHub repo coc-rust-analyzer

    rust-analyzer extension for coc.nvim

  • GitHub repo duct.rs

    a Rust library for running child processes

  • GitHub repo flate2-rs

    DEFLATE, gzip, and zlib bindings for Rust

  • GitHub repo zap

    An asynchronous runtime with a focus on performance and resource efficiency. (by kprotty)

  • GitHub repo rocket_auth

    An implementation for an authentication API for Rocket applications.

  • GitHub repo core-isolation

    Presentation at Lund LinuxCon 2017

  • GitHub repo sdf_2d

    2D Signal Distance Field software (cpu) renderer

  • GitHub repo sleeping_vs_spinning

    Benchmarks for measuring the cost of sleeping compared to spinning

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better tokio-uring alternative or higher similarity.

Posts

Posts where tokio-uring has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-04-11.
  • Is there a lower-latency way of responding to an event than spinning/busy-waiting?
    reddit.com/r/rust | 2021-04-11
    So back to the title: is there a lower-latency way of responding to an event than spinning/busy-waiting? Or more generally, what's the fastest possible way to respond to an I/O event? I have never played with io_uring but this Tokio RFC looks promising. Could io_uring be faster than busy-polling? Or can busy-waiting be used on top of io_uring?
    reddit.com/r/rust | 2021-04-11
    u/The-Best-Taylor: I think you're referring to this Tokio RFC, which will indeed be super interesting to add to the benchmarks when it is better supported!
  • Tokio-Uring Design Proposal
    news.ycombinator.com | 2021-04-08
    news.ycombinator.com | 2021-04-08
  • Tokio-uring design proposal
    reddit.com/r/rust | 2021-04-08
    Rendered version of the markdown ^^
    reddit.com/r/rust | 2021-04-08
    Unfortunately with this proposal the inner parts can't quite be transparent. Workloads will behave differently. If you search for the text Applications must take care to ensure load remains balanced across threads in the DESIGN.md, it explains the main difference and proposes a workaround that may be valid in some situations.
    reddit.com/r/rust | 2021-04-08
  • Hey Rustaceans! Got an easy question? Ask here (14/2021)!
    reddit.com/r/rust | 2021-04-06
    You'd use it whenever you need to do low-overhead asynchronous IO. The first "motivation" paragraph of the tokio-uring design proposal has a brief overview of the benefits of io_uring. In general, as an application developer, you're unlikely to need to use it directly - if you were writing a webserver or something else that needs to a bajillion concurrent connections, you might use an abstraction built on io_uring (like tokio-uring).