Function spawn_blocking 

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

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.