Function serve_on_shared 

pub async fn serve_on_shared<F>(listener: Listener, handler: F) -> Result<()>
where
    F: Fn(HttpRequest) -> HttpResponse + Send + Sync + 'static,

serve_on with a SHARED handler (Fn + Send + Sync) — calls run CONCURRENTLY across connection tasks instead of queueing on one mutex.

★ WHY BOTH EXIST. serve_on serializes deliberately: a LOGOS handler on the interpreter tier is FnMut and single-threaded, and running two turns at once there would not be the same program. A handler that is already Sync has no such constraint, and serializing it anyway makes every SLOW request a stop-the-world event.

That is not hypothetical — it is what the dev server did. largo serve answers its own static assets, its pages and the /__gen reload poll from the same handler that PROXIES to the backend with a multi-second timeout, so one hung route stalled the CSS, the wasm and the reload poll behind it: the page could not even refresh to tell you something was wrong.