Function spawn_blocking 

pub fn spawn_blocking<F, R>(f: F) -> JoinHandle<R> 
where
    F: FnOnce() -> R + Send + 'static,
    R: Send + 'static,

The heavy-work idiom: AsyncValue state, use_task (the blessed load/compute helper), UseTask handle, and spawn_blocking (the CPU-bound entry point) — Frust’s counterpart to Flutter’s compute()/FutureBuilder, with explicit cancellation on component teardown. spawn_blocking joins the existing spawn/spawn_local routing pair (async IO / UI-thread !Send / one-off CPU work). App crates need no new dependency: this is the whole heavy-work surface. See frust_reactive::task for the threading contract. Runs a one-off, blocking CPU workload on the background runtime’s blocking thread pool, returning a JoinHandle to .await its result.

This is the CPU-bound entry point of the heavy-work routing convention:

Call	Use for
frust::spawn	Send async IO-bound work
frust::spawn_local	!Send work that must stay on the UI thread
frust::spawn_blocking	one-off CPU-bound blocking work (JSON parse, decode, hashing)
rayon	data-parallel compute — an app-level choice, deliberately not bundled

The pool already exists (the runtime is built rt-multi-thread), so this is a thin facade over tokio::runtime::Handle::spawn_blocking. Compose it inside a use_task fetcher — use_task(|| async { spawn_blocking(parse).await }) — to get load/error states and cancellation for free.

Cancellation limitation: dropping/aborting the returned handle stops the result from being delivered, but a blocking closure already running cannot be interrupted (there is no safe way to unwind arbitrary blocking code) — the same limitation every runtime has.

No working wasm equivalent yet — fails loudly. wasm32-unknown-unknown has no OS threads, so there is no blocking pool for Handle::spawn_blocking to hand work to (see the module docs). Rather than returning an inert JoinHandle that silently never resolves, this function panics up front on that target (see Panics below), before ever reaching tokio. Treat this as an open gap on wasm, not a proven path — the eventual fix is a browser-thread/Web-Worker-backed JoinHandle, not yet built.

Panics

• Panics if ReactiveRuntime::init has not run yet — the same wiring-bug-not-runtime-condition contract as spawn_local off the UI thread.
• Always panics on wasm32 (see above), independent of init state.