DEV Community: chh-itt

What if reactive effects are just pausable async tasks?

chh-itt — Wed, 13 May 2026 01:24:44 +0000

I've been thinking about reactive programming from the runtime layer up. The question: what's the minimum machinery you actually need to add on top of Rust's async/await to get a working reactive system?

Three things Rust already gives you for free

Pin> = a suspended computation

Think about it: a reactive effect is "a piece of code paused, waiting for its dependencies to change, then re-executing." That's exactly what a future stuck at Poll::Pending is.

scope.spawn(async move {
loop {
count.changed().await; // suspends here
println!("count = {}", count.read());
}
});

The SignalChangedFuture::poll() checks a monotonic version number. If unchanged, it subscribes a callback and returns Poll::Pending. The async executor polls other tasks. When the signal changes, the version bumps, the callback fires, the waker wakes, the executor re-polls. That's the entire effect lifecycle — no custom scheduler, no effect graph traversal, no create_effect() abstraction.

The executor's poll loop IS the effect scheduler. You don't need a separate one.

Waker = the notification dispatcher

A reactive library has to decide "which effects need to re-run when signal X changes." In the async model, this maps directly to "which futures should be re-polled." The waker IS that dispatch mechanism:

fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> PollSelf::Output {
if version_changed {
return Poll::Ready(self.signal.read());
}
// subscribe a callback that calls cx.waker().wake_by_ref()
// executor re-polls this future on next flush
Poll::Pending
}

No separate notification queue. No topological sort of dependents. Just "wake the waker, executor picks it up."

Drop = cleanup

Drop the scope that owns the tasks → all futures drop → each future's Drop impl proactively unsubscribes from its signals → zero dangling subscribers. No manual on_cleanup() tokens, no effect disposal bookkeeping. Rust's ownership does the work.

For deeply nested scopes (think UI component trees with hundreds of levels), cancellation uses BFS to collect all descendants, then iterates leaf-to-root — no recursive drop, no stack overflow.

The 20% Rust doesn't give you: re-entrancy prevention

Here's where pure async breaks down. If Signal::set() calls subscriber callbacks synchronously:

set() → callback → set() on same signal → callback → infinite loop
set() → callback → subscribe new callback → mutate subscriber list during iteration → RefCell panic
set() → callback → drop owning scope → borrow conflict

The async model alone can't prevent this. You need a deferred notification state machine.

The approach: Signal::set() never invokes callbacks directly. It bumps the version, snapshots the subscriber list, and pushes a closure into the executor's deferred callback queue. The executor drains this queue at the start of every flush, before polling any tasks.

Three states, two flags:

notifying = false, dirty = false → normal. Snapshot subscribers, push notification, set dirty.
notifying = true → re-entrant set during callback. Just set dirty, no new notification.
dirty = true, notifying=false → notification already queued. No-op.

After callbacks complete: check dirty. If a re-entrant set() happened during the callback round, schedule a follow-up notification using a fresh subscriber snapshot (so newly-added subscribers from the callback round are included).

This covers every edge case: re-entrant set, subscribe/unsubscribe during callback iteration, scope drop during callback (cancelled flag is a Cell outside the RefCell, always writable), set-from-Drop (deferred to next flush via set_deferred()).

The tradeoff

A traditional reactive scheduler can run effects in topological order — dependencies before dependents, guaranteeing each memo recomputes at most once. An async executor runs tasks in whatever order they wake up. If two effects both read a dirty memo, they might each trigger its recomputation (the second read sees it's already clean and skips the work, but the first poll of each effect triggers the check).

Correctness is preserved — version checking + lazy memo recompute guarantees eventual consistency. But optimality is best-effort, not guaranteed.

For UI frame-level reactivity this is fine. For a compiler's incremental analysis it probably isn't. I think the simplicity trade is worth it for most applications, but I'd be curious to hear counterarguments.

Why bother?

If you squint, reactive programming and async programming are solving the same problem from different directions. One suspends computation waiting for data changes; the other suspends computation waiting for I/O. The primitives overlap almost completely. The question isn't "can you build reactivity on async" — it's "why wouldn't you?"

The only genuinely novel piece needed is a safe way to fire subscriber callbacks without re-entrancy. Everything else is already in the language.

I built a working implementation of this (~1800 lines across two crates, #![forbid(unsafe_code)], zero external deps for the signal layer). I’d genuinely love technical feedback — especially on:

Whether the lack of topological ordering has bitten anyone in real UI projects, or if it’s mostly a theoretical concern.
Whether there’s a simpler alternative to the generational slot table I’m using for executor routing.

If I’ve missed an edge case, or if any of the tradeoffs feel wrong to you, I’m all ears. This is still my own learning process, and I’d rather get corrected now than find out later.

Reactive Programming Doesn't Need a Framework — Ownership Is Enough

chh-itt — Sun, 10 May 2026 08:14:27 +0000

Reactive Programming Doesn't Need a Framework — Ownership Is Enough

How Auralis, a two-crate Rust kernel, reduces reactive programming to things Rust programmers already know.

I spent the last few months building Auralis, a reactive kernel for Rust. Two crates, zero unsafe, signal crate has zero dependencies. It's not a web framework — no view! macro, no DOM, no hydration. Just reactive primitives you pair with whatever you already have.

The core idea fits in one sentence:

Reactive = pausable async tasks. Lifecycle = ownership + structured concurrency.

Everything else follows from this. Let me walk through the design decisions that make it work.

Problem 1: `Signal::set()` can't call subscribers directly

In most reactive systems, changing a signal's value immediately notifies everyone watching it. This seems natural, but it creates a cascade of problems:

A subscriber callback calls set() on another signal → that signal's callback calls set() on the first signal → infinite loop. Or a subscriber tries to subscribe to a new signal during a callback → the subscriber list is being iterated → undefined behavior. Or a subscriber drops itself during a callback → the list iterator points to freed memory.

Every reactive system eventually invents mechanisms to deal with these: pending_unsubscriptions lists, traversal_depth counters, dirty_subscribers sets.

Auralis's answer: don't call subscribers synchronously.

// Signal::set does NOT call callbacks.
// It pushes a notification closure to the executor's deferred queue.
// The executor drains this queue at the start of the next flush.
pub fn set(&self, val: T) {
    let mut state = self.state.borrow_mut();
    state.value = val;
    state.version = state.version.wrapping_add(1); // monotonic version
    let subs = Self::prepare_notification(&mut state);
    drop(state);
    if let Some(subs) = subs {
        Self::schedule_notification(&self.state, subs);
    }
}

The notification closure is a simple Box<dyn FnOnce()>. It captures a snapshot of the subscriber list at the time set() was called. When the executor drains the deferred queue (during the next flush, before polling any tasks), it fires each notification. If a subscriber was added after the snapshot, it won't be called for this change. If a subscriber unsubscribes before the notification fires, an alive flag prevents the callback from running.

This eliminates re-entrancy entirely. No depth counters, no pending-lists, no edge cases. The cost is one microtask of latency — negligible for any actual use case.

The state machine for a single signal notification looks like this:

set() → prepare_notification → schedule_notification
         ↓ (already notifying?)    ↓ (inside batch?)
         dirty=true, return        buffer, flush at batch end
                                   ↓
                              executor flush
                                   ↓
                              call subscribers
                                   ↓ (re-entrant set during callback?)
                              dirty=true, schedule follow-up

Problem 2: Cancelling background work is hard. Dropping a scope is easy.

Every Rust UI eventually hits the same problem: the user navigates away, but the HTTP request is still in flight. The component is unmounted, but the timer is still ticking. You need cancellation tokens, AbortHandles, or manual Arc<AtomicBool> flags scattered everywhere.

Auralis replaces all of that with TaskScope. When a scope is dropped, all tasks spawned inside it — and all descendant scopes — are cancelled. No tokens, no handles, no manual cleanup.

let scope = TaskScope::with_executor(&ex);

// Spawn a task that listens to a signal.
scope.spawn(async move {
    loop {
        let val = count.changed().await;
        render(val);
    }
});

// Spawn another task that runs a timer.
scope.spawn(async move {
    timer::sleep(Duration::from_secs(5)).await;
    cleanup();
});

// Later, when the UI component is unmounted:
drop(scope);
// Both tasks are cancelled. No tokens, no handles.

The cancellation itself is iterative, not recursive. TaskScope::drop does a BFS traversal of the scope tree, collects all descendants, then cancels them leaf-to-root. This means a 200-level nested UI tree drops without stack overflow — no #[rustc_recursion_limit] hacks needed.

The cancellation uses the same Rc<RefCell<TaskScopeInner>> that Memo uses. When the last TaskScope clone is dropped (Rc::strong_count == 1), the cancellation runs. Temporary clones — from find_scope during executor flush, from with_current_scope during spawn — are harmless. They share the same Rc and don't trigger cancellation. This is a bug we actually found and fixed in development — a temporary clone was setting cancelled = true on the shared inner, and subsequent spawns silently returned.

Problem 3: Derived state goes stale when you forget to update it

In immediate-mode GUIs (like egui), everything is recomputed every frame. This is simple but wasteful. In retained-mode UIs, derived state must be manually updated when dependencies change. This is efficient but error-prone — one missed update and the UI shows stale data.

Memo solves this by being both lazy and automatic. You give it a closure. It runs the closure once, discovers which signals were read, and subscribes to them. When a source signal changes, the memo just flips a dirty flag. The actual recomputation is deferred until someone calls memo.read().

let raw_data = Signal::new(load_large_dataset());
let filter_params = Signal::new(FilterParams::default());

// Memo auto-tracks which signals it reads.
let filtered = memo!(raw_data, filter_params =>
    filter(&raw_data.read(), &filter_params.read())
);

let aggregated = memo!(filtered =>
    aggregate(&filtered.read())
);

let formatted = memo!(aggregated =>
    format_results(&aggregated.read())
);

// Cache hit when params haven't changed: < 0.01 ms
// Cache miss when params changed: ~14 ms (500K records)

The memo! macro handles the boilerplate of cloning signals before the move closure:

// Without macro:
let f = Memo::new({ let a = a.clone(); let b = b.clone(); move || a.read() + b.read() });

// With macro:
let f = memo!(a, b => a.read() + b.read());

We benchmarked this against two alternatives on a 500K-record 3-stage pipeline:

Change rate	Recompute every frame	Manual cache	Auralis Memo
1% (typical UI)	~14 ms/fr	0.14 ms/fr	0.16 ms/fr
10%	~14 ms/fr	1.45 ms/fr	1.78 ms/fr
50% (worst case)	~14 ms/fr	7.33 ms/fr	9.09 ms/fr

At realistic UI change rates (< 1%), Memo provides ~90x speedup. Cache-hit cost is literally a Cell::get + Rc deref — under 10 microseconds.

The 50% row is the interesting one. Memo has ~24% overhead vs. a hand-written cache (9.09 vs 7.33 ms/fr). This is the cost of not writing invalidation logic by hand. A hand-written cache for a 3-stage pipeline needs ~20 lines of if filter_changed || agg_changed || fmt_changed cascade. Add a stage, you add 2–3 more condition checks. Miss one, you get stale data.

With Memo, adding a stage is one line: memo!(prev_stage => compute(&prev_stage.read())). The dependency graph is maintained automatically.

Problem 4: `Arc<Mutex<T>>` is wasteful when you're single-threaded

Most Rust reactive libraries reach for Arc<Mutex<T>> so they can be Send + Sync. On single-threaded Wasm — which is the primary target for many Rust UI frameworks — atomics are pure overhead. Every lock() is effectively a no-op, but you pay the code size and mental overhead anyway.

Auralis goes the other way: Signal<T> and TaskScope are deliberately !Send + !Sync. They use Rc<RefCell<T>> throughout — zero atomics, zero lock overhead. The Wasm binary for a minimal reactive counter compiles to a few tens of KB.

For multi-threaded scenarios, the escape hatch is instance isolation, not shared mutable state:

// Thread 1
let ex1 = Executor::new_instance();
let scope = TaskScope::with_executor(&ex1);
// scope holds a strong reference to ex1

// Thread 2 — completely independent
let ex2 = Executor::new_instance();
let scope2 = TaskScope::with_executor(&ex2);

// Communication between threads: channels, not shared signals.
// See examples/multi_thread_bridge.rs for a 6-line pattern.

This mirrors tokio's single-threaded runtime model: each executor is a self-contained event loop. Tasks in different executors don't interact. Cross-executor communication uses channels.

TaskWakers carry a (slot_id, generation) pair — a thread-local slot table maps these to Weak<RefCell<Executor>>. The generation counter invalidates stale wakers after an executor is destroyed. Zero unsafe code in the entire routing system.

What we learned

Deferred callbacks are worth the microtask. The signal notification state machine went through multiple iterations, but the core idea — never call subscribers synchronously — survived every rewrite. It eliminates an entire class of bugs at the architectural level.
Ownership is a better lifecycle manager than any framework API. drop(scope) is simpler, more composable, and harder to misuse than on_cleanup, AbortHandle, CancellationToken, or any other explicit cancellation mechanism. The compiler enforces it.
Build the kernel, not the framework. Auralis has no DOM, no renderer, no router. This means it can be used in a CLI app (we have a demo), in a Wasm browser app (we have a demo), in an egui desktop app (we have a demo), or in any other scenario involving "signal change → async task reaction → automatic cleanup."
Benchmarks are invaluable for design decisions. The incremental Memo subscription diff — keeping shared dependencies and only subscribing to new ones — was motivated by a benchmark showing 30x slowdown at high change rates. We found the bug, fixed it, and the performance returned to expected levels.
Was found a non-obvious bug by building a Wasm demo. The TaskScope clone-from-find_scope was setting cancelled = true on the shared inner when dropped after a task poll, silently preventing future spawns. This only manifests in long-running apps (like Wasm pages) where the scope outlives a single flush cycle. The fix — checking Rc::strong_count == 1 before cancelling — matches Memo::drop's behavior.

Try it

The crates are on crates.io at v0.1.6:

[dependencies]
auralis-signal = "0.1"
auralis-task = "0.1"

All demos are runnable — clone the repo and cargo run / trunk serve any of them.

GitHub: github.com/chh-itt/auralis
Docs: docs.rs/auralis-signal / docs.rs/auralis-task

If you're building something reactive in Rust and want a kernel that stays out of your way — or if you have opinions on the API — I'd love to hear from you.

DEV Community: chh-itt

What if reactive effects are just pausable async tasks?

Reactive Programming Doesn't Need a Framework — Ownership Is Enough

Reactive Programming Doesn't Need a Framework — Ownership Is Enough

Problem 1: Signal::set() can't call subscribers directly

Problem 2: Cancelling background work is hard. Dropping a scope is easy.

Problem 3: Derived state goes stale when you forget to update it

Problem 4: Arc<Mutex<T>> is wasteful when you're single-threaded

What we learned

Try it

Problem 1: `Signal::set()` can't call subscribers directly

Problem 4: `Arc<Mutex<T>>` is wasteful when you're single-threaded