Problem

Nothing pumps the V8 platform's foreground task queues. v8::platform::PumpMessageLoop only ran inside the WASM-scoped MessageLoopTimer (an ALooper fd fed by a detached thread polling every 100ms, wrapped around WebAssembly.compile/instantiate via JS proxies) and the inspector pause loops. Everything else V8 posts to its foreground runner just sat there:

• Atomics.waitAsync promises never resolved (their wakeup is a foreground task).
• GC finalization / heap tasks never ran.
• Async WASM compilation resolved with up to 100ms latency, and only while the proxy's start/stop window was open.

Separately, the runtime had grown four bespoke implementations of "get work onto a runtime thread": TimerHandler tokens, LooperTasks' eventfd, the worker inbound eventfd queue, and (in this PR's first cut) another token Handler for platform tasks.

Change: a per-runtime EventLoop with two lanes

Each Runtime now owns an EventLoop (the Android analogue of the iOS runtime's ExecuteOnRunLoop seam), bound to its thread in PrepareV8Runtime. Work is routed by ordering contract:

Ordered lane — work whose ordering is observable against app-level Java messages. Rides the Java MessageQueue via a dedicated com.tns.EventLoopHandler using anonymous "task due" tokens (the Timers scheme from bfd7650), so it is strictly FIFO with Handler.post runnables and JS timers. First producer: __ns__queueMacrotask(cb), the seam future spec'd macrotasks (e.g. performance-observer callbacks) will use.

Internal lane — work in its own ordering domain: v8 platform foreground tasks (WASM finalization, Atomics.waitAsync wakeups, GC tasks), worker→parent messages, unhandled-rejection drains. Rides an EFD_SEMAPHORE eventfd plus one timerfd (armed to the earliest delayed due time) on the thread's ALooper — Chrome's MessagePumpAndroid shape. No JNI on the post path, so V8's non-JVM worker threads post without attaching to the JVM. One eventfd unit = one unit of work per looper callback, so bursts interleave fairly with Java messages instead of draining in one go.

NativeScriptPlatform wraps the default platform (workers/jobs/time/tracing delegate to libplatform) and serves GetForegroundTaskRunner(isolate) from the isolate's EventLoop. The loop starts unbound and buffers (v8 requests the runner during Isolate::New); binding flushes. Each executed entry ends with a microtask checkpoint — work like the waitAsync wakeup resolves promises without entering JS, which kAuto's depth-0 drain never sees. Shutdown drops queued work and late posts, mirroring the old LooperTasks "message to a terminated runtime" semantics; leftover wakeups no-op like cleared-timer tokens.

Inspector pause loops (where the looper isn't polling) drain only nestable v8 tasks, bounded to the entries present at call time; non-nestable tasks and plain posts run from their own wakeups after the pause unwinds — matching the old PumpMessageLoop + LooperTasks behavior split.

Removed

• MessageLoopTimer (polling thread, pipe, WebAssembly proxies in message-loop-timer.js) — async WASM promises now resolve promptly with no start/stop windows.
• LooperTasks — consolidated into the internal lane; call sites (worker messaging, exception drains) ported 1:1 including the weak_ptr child semantics and drop-after-shutdown behavior.

Timers deliberately stays separate: it is the ordered lane specialized with sub-millisecond ordering machinery, and it is battle-tested.

Not in this PR

Microtask policy is untouched (kAuto). The cross-thread microtask-drain design (continuations always landing on the runtime thread under multithreaded JS) builds on this seam later.

Tests

• testEventLoop.js: Atomics.waitAsync notify/timeout/mismatch + promise-chain ordering (the async cases hang without this change), plus ordered-lane specs: __ns__queueMacrotask async delivery, runs-after-microtasks, FIFO interleaving with setTimeout(0), TypeError on non-function.
• Existing async-WASM, worker messaging, and error-event suites exercise the internal lane's ported paths.

Post-review hardening

An independent deep review of the scheduler surfaced two defects, both fixed here:

• Internal-lane unit starvation: an eventfd unit written for an immediate entry could be spent on a due-but-unsignaled delayed entry (its timerfd unit not yet issued); the later timerfd fire then found nothing due and issued nothing, leaving the lane permanently off-by-one — the most recently posted entry always waited for a future post. The unit-consuming path now skips unsignaled delayed entries; nested (unit-free) drains and the ordered lane are unaffected. Regression test: worker reply racing an overdue Atomics.waitAsync timeout.
• Stale loop registry across isolate-pointer reuse: the registry entry was erased in ~Runtime, which runs several JNI calls after Isolate::Dispose frees the address — a concurrently created worker isolate could reuse the pointer and inherit the dead runtime's stopped loop (dropping all its work), and the late destructor could then evict the new tenant's entry. Fixes: matched erase (only removes the entry while it still maps to the disposing runtime's loop) immediately after Dispose, PrepareV8Runtime refreshes a stopped loop found under its key, and the v8 task runner resolves the loop through the registry on every post so a refresh redirects already-handed-out runners.

Also from review: the inspector-pause drain guards against C++ exceptions unwinding through v8 inspector frames, and fd callbacks ignore spurious wakeups (read failure) instead of consuming an entry.

Semantic deltas vs the old LooperTasks (deliberate): worker→parent messages now run one-per-looper-poll instead of batch-per-wakeup (Java messages interleave between them; relative order preserved), and each entry is followed by a Locker + microtask checkpoint. Open question flagged by review: microtask checkpoints currently run during debugger pauses (Blink parity) — see PR discussion.

Review sequencing, applied on this PR

Per the design review's sequencing (everything except the kExplicit microtask work, which remains a follow-up):

Timers merged into the ordered lane (with tombstones). TimerHandler is deleted; timers post anonymous tokens through the EventLoop, and the token drain runs the earliest due item across timers and ordered macrotasks — one due-ordered domain, still strictly FIFO with Handler.post. clearTimeout now leaves a tombstone whose own token consumes it as a no-op, so no token gains surplus capacity to run a later-scheduled item ahead of foreign Java messages between the two token positions — this also fixes the pre-existing congestion deviation in shipped timers. FireTimer's internals (sub-ms sorted list, interval catch-up, nesting clamp) are untouched; the check-and-run is a single RunIfEarliest call under one Locker acquisition, since background threads mutate timer bookkeeping via setTimeout under multithreaded JS.

__runOnMainThread promoted into the internal lane. The 2MB main-looper pipe is gone; closures ride bare internal-lane entries that skip the loop's Locker/checkpoint — the closure locks the caller's isolate, and taking the main isolate's Locker first would nest Lockers across isolates (deadlock-capable against worker→main entry paths, per review). Delivery stays one-per-poll like the old fd callback. Incidental fixes: the callback cache is now mutex-guarded (it was written from arbitrary threads whose different-isolate Lockers provided no mutual exclusion), and uncaught callback exceptions surface as pending Java exceptions instead of unwinding C++ through the ALooper frame.

Not applied: kExplicit microtask policy (excluded by request) and the internal-lane budgeted batch drain (the review gates it on profiling evidence; the old pipe was also one-per-poll, so there is no parity argument for it).

Cancellable timer tokens (wakeup hygiene for debounce workloads)

Tombstones fix ordering but leave a cleared timer's wakeup in the queue — a no-op that still wakes the looper at due time and, worse, acquires the isolate Locker (a stale token could park the main thread behind a long background JS turn under multithreaded JS). Cancelled timers now neutralize their token, in two tiers by remaining delay:

• < 32ms — native claim cells. The token carries a slot from a fixed per-loop atomic table (indexed by timer id, id embedded in the cell word so cancellation can never hit a recycled cell). clearTimeout is a single native CAS — zero JNI: winning proves the token dead (sorted entry erased outright); losing leaves a tombstone for the in-flight token. EventLoopHandler claims cells via a @CriticalNative CAS (public API in current SDKs; degrades to plain JNI with identical semantics where unapplied) before entering the runtime — a cancelled token dies in Java in nanoseconds, never touching the Locker. Cells see exactly one gate pass by construction (only the gate retires; cell tokens are never removed), and a busy slot just downgrades to plain+tombstone.
• ≥ 32ms — identified tokens. The token carries a GC-owned AtomicBoolean peer claimed in handleMessage; clearing CASes it and, on winning, removeMessages()es the queued token — a cleared debounce timer produces no wakeup at all. The CAS makes the removal-vs-in-flight race harmless: a lost race costs one no-op wakeup, never an ordering violation. Below the cutoff a stale wakeup lands within two frames of the interaction that scheduled it (app provably awake), so the zero-allocation path applies.

The cutoff is a fixed constant (32ms): timer delays cluster bimodally (0–16ms scheduling/animation vs ≥100ms debounce/timeouts), and the identified clear is a net lifetime JNI reduction (one clear-time crossing replaces a deferred full dispatch). Only the newest token of an interval is cancellable; older re-arm-orphaned tokens keep functioning anonymously, preserving token/slot parity under anonymous dispatch.

Verified on device: the orphan-token ordering probes pass 100% across every scenario (timer-FIFO ties, clear-vs-Handler.post in both orders, orphan-across-gap, triple-clear, clearInterval from its own callback, starvation after heavy clearing), and the full suite is green (78 suites / 668 specs) including new specs for identified clears, a background-thread clear racing dispatch (multithreaded JS), and interval stop.

Summary by CodeRabbit

• New Features

  • Added a unified event-loop system for foreground tasks, timers, workers, and callbacks.
  • Added ordered macrotask scheduling and support for queuing macrotasks.
  • Improved coordination of asynchronous waits, timer cancellation, worker messages, and runtime lifecycle events.

• Bug Fixes

  • Improved task ordering, timer consistency, thread affinity, cancellation races, and cleanup during shutdown.

• Tests

  • Added comprehensive event-loop coverage for asynchronous waits, timers, validation, worker communication, cancellation, and repeated worker lifecycles.