Event loop blocking limits during CPU-intensive go-blocks

Direct Answer

No, core.async does not provide a built-in preemptive yield primitive. A go-block only relinquishes control at explicit asynchronous boundaries—channel takes (<!), puts (>!), alt!, or timeout. Pure synchronous CPU work inside a go-block runs to completion on the host’s single thread, blocking all other tasks, timers, and UI updates.

Why This Happens

In ClojureScript, go-blocks compile to state machines executed on the JavaScript main thread. The state machine advances only when the code reaches a channel operation that can park. Between those points, execution is synchronous and uninterruptible. There is no scheduler tick, no yield keyword, and no documented API to force a cooperative yield without introducing an asynchronous boundary.

Established Mitigation Patterns

1. Offload to a Separate Thread (Recommended for Heavy Work)

• Browser: Use a WebWorker. Serialize input, postMessage, receive result via promise/channel bridge.
• Node.js: Use worker_threads with MessagePort or a promise-based wrapper.
• Both approaches move computation off the event loop entirely. Startup and serialization cost mean this pays off for work exceeding ~10–50 ms.

2. Chunk with Explicit Yields Inside the Go-Block

If the work must stay in-process, break it into small chunks and insert a zero-delay timeout between chunks:

(go
  (doseq [chunk (partition 1000 large-coll)]
    (process-chunk chunk)
    (<! (async/timeout 0)))) ; yields to event loop

Each (async/timeout 0) parks the state machine, returns control to the host, and resumes on the next microtask/macrotask tick. Tune chunk size so no single chunk blocks longer than ~16 ms (one frame).

3. Schedule via requestIdleCallback (Browser) or setImmediate (Node)

For background work that can tolerate deferral, wrap chunks in a promise resolved by requestIdleCallback and <! the promise via async/promise-chan. This lets the browser prioritize UI work.

Choosing a Pattern

Constraint	Preferred Approach
Work > 50 ms, independent data	Web Worker / worker_threads
Work 1–50 ms, must share ClojureScript state	Chunk + (<! (async/timeout 0))
Low-priority background, browser only	requestIdleCallback + promise-chan

Verification Steps

1. Add a recurring js/setTimeout logging timestamps; observe gaps during the heavy go-block.
2. In Chrome DevTools, record a Performance trace; look for long tasks (>50 ms) on the main thread.
3. In Node, use perf_hooks.monitorEventLoopDelay() to quantify lag.

One Missing Detail

Are you targeting the browser or Node.js? The offloading APIs (Web Workers vs. worker_threads) and idle-callback availability differ, so the exact implementation changes.