You are designing a browser worker pool that processes large binary frames. How do you decide between transferring ArrayBuffers back and forth and putting the data in a SharedArrayBuffer that all the workers read?

## Frame the choice as an ownership question Both mechanisms avoid copying. The difference is not performance, it is **how many agents may touch the bytes at once**. Transfer is a *move*: after `postMessage(buf, [buf])`, the sender's buffer is detached and only the receiver can read or write it. Exclusivity is enforced by the platform, not by convention. `SharedArrayBuffer` is *shared*: every agent that holds it sees the same memory simultaneously. Nothing stops two workers writing the same slot in the same instant, so correctness now depends on you coordinating access with `Atomics`. So the decision procedure is: describe the access pattern honestly. "One frame, one worker, then the result comes back" is a handoff, and transfer expresses it exactly. "Eight workers scan the same 200 MB asset while a producer appends to it" is concurrent access, and no amount of message passing makes that cheap. ## The case for transfer as the default Transfer costs nothing to deploy. It works on any page, over any origin, with any third-party scripts embedded, today. It is O(1) in buffer size. And the detachment semantics turn a whole class of concurrency bugs into a hard failure: if you write through a stale view after handing the buffer off, the write is silently dropped or the next view construction throws — bad, but local and findable, unlike a torn read. The pattern that makes transfer practical for a steady stream is a **buffer pool with ping-pong ownership**. Allocate N buffers up front, transfer one into a worker with the job, and have the worker transfer the *same* buffer back with its result. No allocation churn, no copying, and the pool size caps memory. With `navigator.hardwareConcurrency` workers and a couple of buffers in flight per worker, this saturates a pool without ever sharing a byte. What transfer cannot express: two agents needing the data at the same instant, or a producer that keeps appending while consumers read. Splitting the data so each worker owns a disjoint slice often rescues the design — if frames are independent, they are separate buffers, and the shared-memory case evaporates. ## The bill for SharedArrayBuffer Three costs, in the order that hurts. **Deployment.** `SharedArrayBuffer` exists only in a cross-origin isolated document: `Cross-Origin-Opener-Policy: same-origin` plus `Cross-Origin-Embedder-Policy: require-corp` on every HTML route, verified at runtime as `self.crossOriginIsolated`. That forces every cross-origin subresource to opt in and severs popup opener links. On a product with ad tags, embedded video and an OAuth popup, this is a cross-team migration, not a header. **Correctness.** Once memory is shared you own the synchronization. `Atomics.load`/`store`/`compareExchange` for the coordination slots, `Atomics.wait`/`notify` between workers — and remember the page's main thread is not allowed to block, so the waiting must live in workers. These bugs are timing-dependent: they pass in review, pass in CI, and appear on one user's eight-core laptop under load. **Maintenance.** A shared arena has no type checker. The layout — which offsets mean what, who may write which region — lives in comments and discipline. Every future contributor can violate it from anywhere. ## When shared memory is the right answer It earns its keep when the access pattern is inherently concurrent and the data is large enough that partitioning is not viable: a threaded WebAssembly runtime that expects a shared linear memory, an audio pipeline where a real-time thread and a UI thread meet at a lock-free ring buffer, a large read-only asset several workers index simultaneously. Note that the read-only case is the mildest — sharing an immutable buffer needs no atomics at all beyond publication, and is much easier to defend than a mutable arena. ## How I would actually run the decision Build the transfer version first, with a pooled ping-pong protocol, and measure. If the numbers meet the target, stop — you have avoided a document-wide policy change and an entire bug class. If they do not, identify precisely *why*: copying you failed to eliminate, message frequency, or genuine concurrent access. Only the third justifies shared memory. If you do adopt it, confine the shared region behind a small module with a documented layout, keep every blocking wait inside workers, and gate the whole path on `self.crossOriginIsolated` with a transfer-based fallback, because a route can lose isolation for reasons your team does not control.