Module dispatch_sm 

SpiderMonkey Jsc/Js arm adapters for bun_dispatch::link_interface!.

Bao replaces JavaScriptCore with SpiderMonkey. The dispatch variants Jsc (in bun_event_loop::JsEventLoop[Jsc], bun_ast::TranspilerCacheImpl[Jsc]) and Js (in bun_io::EventLoopCtx[Js, Mini]) are upstream implemented in bun_jsc; Bao’s bao_engine provides the SpiderMonkey equivalents here.

Backing store design

BaoEventLoop is a per-thread single instance wrapping a bun_event_loop::MiniEventLoop<'static>. The MiniEventLoop contributes the uSockets event loop, task queue, pipe-read buffer, and file-poll store — SpiderMonkey adds the JS context on top.

Reusing MiniEventLoop is sound because dispatch dispatches on the variant tag (Js vs Mini), not on the backing struct identity. EventLoopCtx[Js] dispatch through BaoEventLoop while EventLoopCtx[Mini] dispatch through MiniEventLoop directly — the two arms don’t share an owner pointer.

Lazy initialization

MiniEventLoop::init() is non-const, so BaoEventLoop stores Option<MiniEventLoop> and lazily materializes the inner on first access. This mirrors JSC’s VirtualMachine::get() lazy thread-local pattern.

Variant naming

We reuse the upstream Jsc / Js variant identifiers — the variant label is a link-time symbol token, not an engine identity claim. Keeping the upstream name minimizes diff vs. Bun and avoids touching the interface declarations in low-tier crates.

Wave 73 sub-wave map

• 73-A: this file — framework + BaoEventLoop skeleton [COMPLETED]
• 73-D: EventLoopCtx[Js] arm (bun_io::link_impl_EventLoopCtx!) — 11 methods [IN PROGRESS]
• 73-E: JsEventLoop[Jsc] arm (bun_event_loop::link_impl_JsEventLoop!) + __bun_js_event_loop_current
• 73-G: integration — bao_runtime drops hand-written TimerHeap
• 73-B/C/F: CANCELLED — ProcessExit/OutOfMemoryHandler/VmLoaderCtx have no Jsc variant

Structs

BaoEventLoop

Per-thread Bao event loop backing the Js/Jsc arm of every dispatch interface in this module.

Functions

__bun_js_event_loop_current