Skip to content
tezvyn:

Pass data to a Web Worker and transfer an ArrayBuffer efficiently

Source: developer.mozilla.orgMediumHow cards are made

Pass data to a Web Worker and transfer an ArrayBuffer efficiently

Tests postMessage clone versus transferable objects for zero-copy transfer. Good answers note postMessage copies by default, but ArrayBuffer can move via transfer list, neutering the original.

What's really being asked

This question evaluates your understanding of the Web Worker communication model, specifically the structured clone algorithm versus transferable objects. Interviewers want to see that you know the default postMessage behavior incurs copying overhead, and that you can optimize large binary data transfers using zero-copy memory moves. It also checks whether you understand thread safety implications, since transferring ownership prevents concurrent access bugs.

The full answer

First, explain that data is sent to a worker via worker.postMessage(data), which by default uses the structured clone algorithm to duplicate the data in the worker context. Second, state that for large ArrayBuffers you should use the transfer list in the second argument like worker.postMessage(data, [arrayBuffer]). Third, clarify that this transfers ownership of the underlying memory resource from the main thread to the worker in a zero-copy operation. Fourth, emphasize that after transfer the original ArrayBuffer is neutered, its byteLength becomes zero, and any read or write attempt throws an exception. Fifth, note that TypedArrays like Uint8Array are serializable but not themselves transferable, only their underlying buffer is transferable.

The mistakes people make

Saying you pass the buffer in postMessage without mentioning the transfer list, which means it gets cloned and doubles memory usage. Claiming that TypedArrays are transferable rather than their ArrayBuffer. Suggesting JSON stringify as an alternative for binary data, which is both slow and lossy. Failing to mention that the original buffer becomes unusable after transfer, which can cause runtime exceptions if the main thread tries to reuse it. Proposing SharedArrayBuffer without being asked, without explaining the Spectre-related security constraints and context requirements.

What usually comes next

How would you return the processed buffer back to the main thread? The answer is the same transfer mechanism from the worker via self.postMessage(result, [buffer]). What if both threads need simultaneous read access? Then you would discuss SharedArrayBuffer and Atomics, but note the cross-origin isolation requirements. How do you handle browsers that do not support transferable objects? Modern browsers all do, but polyfills or falling back to structured clone is the historical answer. What other objects are transferable? MessagePort, ImageBitmap, OffscreenCanvas.

A concrete example

Suppose you have an 8MB Uint8Array on the main thread. You create a worker and call worker.postMessage(uInt8Array, [uInt8Array.buffer]). Inside the worker you receive the event and can read the Uint8Array from e.data. Meanwhile on the main thread uInt8Array.buffer.byteLength is now zero. Attempting to access uInt8Array[0] throws. This proves the memory was moved, not copied, avoiding an 8MB duplication and the associated garbage collection cost.

Interview question

After calling worker.postMessage(uint8Array, [uint8Array.buffer]), what is the state of uint8Array on the main thread?

  • a.Its underlying buffer is neutered and any access throws an exception.Correct
  • b.It is deep-copied, so both threads have independent 8MB buffers.
  • c.It shares memory with the worker, allowing concurrent reads from both threads.
  • d.It remains usable because the transfer list is only a performance hint and does not affect ownership.
Why?

Transferring the ArrayBuffer moves ownership to the worker and neuters the original buffer to prevent concurrent access, so main-thread reads or writes throw. Distractor A describes the default structured clone behavior when no transfer list is provided, which duplicates memory rather than performing a zero-copy move.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles