This is an automated email from the ASF dual-hosted git repository. gkoszyk pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/iggy-website.git
commit 0f289fc857aeee0c134b19d61e8c670bab8b102d Author: numinex <[email protected]> AuthorDate: Fri Feb 27 00:07:49 2026 +0100 some more improvements --- content/blog/thread-per-core-io_uring.mdx | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/content/blog/thread-per-core-io_uring.mdx b/content/blog/thread-per-core-io_uring.mdx index c344680d..7b4df1bb 100644 --- a/content/blog/thread-per-core-io_uring.mdx +++ b/content/blog/thread-per-core-io_uring.mdx @@ -177,13 +177,13 @@ To submit a batch while preserving operation order, one must use the io_uring ch ## The state of Rust async runtimes ecosystem -The problem is twofold: at the time of writing this blog post, there is no Rust equivalent of the `Seastar` framework. That is unfortunate, because `glommio` attempted to be one, but things changed: Glauber moved on to work on `Turso`, and the Datadog team does not seem to be actively maintaining the runtime while building [a real-time time-series storage engine in Rust for performance at scale](https://www.datadoghq.com/blog/engineering/rust-timeseries-engine/). They mention `sharding` [...] +The problem is twofold: at the time of writing this blog post, there is no Rust equivalent of the `Seastar` framework. That is unfortunate, because `glommio` attempted to be one, but things changed: Glauber moved on to work on [Turso](https://github.com/tursodatabase/turso), and the Datadog team does not seem to be actively maintaining the runtime while building [a real-time time-series storage engine in Rust for performance at scale](https://www.datadoghq.com/blog/engineering/rust-times [...] Secundo problemo is that these runtimes imitate the `std` library APIs, which is `POSIX` compliant, while many of `io_uring`'s most powerful features are not, leaving those capabilities out of reach for us mere mortals. Request chaining is only the tip of the iceberg, there is plenty more, for example `oneshot` APIs for listen/recv, `registered buffers`, and so on. Ultimately, `File`, `TcpListener`, and `TcpStream` are not the right abstractions. From the point of view of `POSIX` complia [...] It seems like we are not the only ones that are aware of that problem: [Microsoft recently announced a thread-per-core async runtime](https://www.reddit.com/r/rust/comments/1p1flpx/kimojio_a_threadpercore_linux_io_uring_async/), that uses `Operation` as the unit of abstraction, this is a much better idea. -It's worth noting that one of the key reasons we ended up going with `compio` is that they want to move with the times and expose more and more `io_uring` APIs. Their codebase is structured so that the driver is decoupled from the executor, I would push the pluggability even further. A very hot topic in distributed systems these days is `DST` (Deterministic Simulation Testing): the idea is to replace all non-deterministic sources in your system (network, block devices, time, etc.) with d [...] +It's worth noting that one of the key reasons we ended up going with `compio` is that they want to move with the wind of time by exposing more and more `io_uring` APIs. Their codebase is structured so that the driver is decoupled from the executor, I would push the pluggability even further. A very hot topic in distributed systems these days is `DST` (Deterministic Simulation Testing): the idea is to replace all non-deterministic sources in your system (network, block devices, time, etc. [...] ## Benchmarks @@ -215,8 +215,6 @@ The difference wasn't that big, `tokio` managed to keep up decently well with 8 ### 32 Partitions -The gains compound further as partition count doubles: - **v0.5.0** with `tokio` 
