This is an automated email from the ASF dual-hosted git repository.
hgruszecki pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/iggy-website.git
The following commit(s) were added to refs/heads/main by this push:
new ac3ca71a Clarify io_uring blogpost sections (#36)
ac3ca71a is described below
commit ac3ca71a2e00b74e4d52e8136ba5396341d87b89
Author: Hubert Gruszecki <[email protected]>
AuthorDate: Fri Feb 27 09:15:33 2026 +0100
Clarify io_uring blogpost sections (#36)
---
content/blog/thread-per-core-io_uring.mdx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/content/blog/thread-per-core-io_uring.mdx
b/content/blog/thread-per-core-io_uring.mdx
index 0f9f732b..0ae93279 100644
--- a/content/blog/thread-per-core-io_uring.mdx
+++ b/content/blog/thread-per-core-io_uring.mdx
@@ -13,9 +13,9 @@ At Apache Iggy, performance is one of our core principles. We
take pride in bein
To explain the "whys" of that decision in detail, a quick primer on the status
quo is needed.
Apache Iggy utilized `tokio` as its async runtime, which uses a multi-threaded
work-stealing executor. While this works great for a lot of applications (work
stealing takes care of load balancing), fundamentally it runs into the same
problem as many "high-level" libraries: a lack of control.
-When `tokio` starts, it spins up `N` worker threads (typically one per core)
that continuously execute and reschedule `Futures`. The scheduler decides on
which worker a particular `Future` gets to run, which can potentially lead to a
lot of context switches, cache invalidations, and unpredictable execution
paths. While Rust `Send` and `Sync` bounds eliminate many of the data races
associated with multi-threaded programming, there are still bunch of footguns
left open, such as [deadlocks] [...]
+When `tokio` starts, it spins up `N` worker threads (typically one per core)
that continuously execute and reschedule `Futures`. The scheduler decides on
which worker a particular `Future` gets to run, which can lead to task
migrations between workers, cache invalidations, and less predictable execution
paths. While Rust `Send` and `Sync` bounds prevent data-race undefined
behavior, they do not prevent higher-level concurrency bugs such as
[deadlocks](https://github.com/apache/iggy/pull/1567).
-But even these challenges weren't what finally tipped us over the edge. The
way `tokio` handles block device I/O was the real dealbreaker. Tokio, following
the poll-based Rust `Futures` model, uses (depending on the platform) a
notification-based mechanism to perform I/O on file descriptors. The runtime
subscribes for a readiness notification for a particular descriptor and
`awaits` the readiness in order to submit the I/O operation. While this works
decently well for network sockets, it [...]
+But even these challenges weren't what finally tipped us over the edge. The
way `tokio` handles block device I/O was the real dealbreaker. Tokio, following
the poll-based Rust `Futures` model, uses (depending on the platform) a
notification-based mechanism to perform I/O on file descriptors. The runtime
subscribes for a readiness notification for a particular descriptor and
`awaits` the readiness in order to submit the I/O operation. While this works
decently well for network sockets, it [...]
## Thread per core shared nothing architecture
The thread-per-core shared-nothing architecture is what we landed on when it
comes to improving the scalability of Apache Iggy. It has been proven to be
successful by high-performance systems such as
[ScyllaDB](https://github.com/scylladb/scylladb) and
[Redpanda](https://github.com/redpanda-data/redpanda), both of those projects
utilize the [Seastar](https://github.com/scylladb/seastar) framework to achieve
their performance goals.
@@ -51,7 +51,7 @@ At first glance since the thread-per-core shared-nothing
model all state is loca
> thread 'shard-8' (496633) panicked at
> core/server/src/streaming/topics/helpers.rs:298:21:
RefCell already borrowed
-Turns out that `RefCell` isn't safe to use across an `.await` point, there is
even clippy lint for that - `clippy::await_holding_refcell_ref`.
+Turns out that holding a `RefCell` borrow across an `.await` point can cause
runtime borrow panics, there is even a clippy lint for that -
`clippy::await_holding_refcell_ref`.
The Rust `wg-async` (async working group) seems to be aware of that footgun
and describes it in [this
story](https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_wants_to_use_ghostcell.html).
It *feels* like it should be possible to express statically-checked borrowing
for `Futures` using primitives such as `GhostCell`, they even share a
[proof-of-concept runtime](https://crates.io/crates/stakker) that does exactly
that, but achieving an ergonomic API indistin [...]
