<p dir="auto">In browsers, sending large array buffers over postMessage, for example to a <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API" rel="nofollow">Worker</a>, can be optimized by indicating that an ArrayBuffer (which is <a href="https://developer.mozilla.org/en-US/docs/Web/API/Transferable" rel="nofollow">Transferable</a>) should transfer ownership, instead of being cloned. See the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage#parameters" rel="nofollow">transfer parameter</a> to postMessage on MDN.</p>
<p dir="auto">This does not appear to be working in Deno 1.12.2: <code class="notranslate">const tmp = new Uint8Array(0); w.postMessage({ tmp }, [ tmp.buffer ]);</code> throws <code class="notranslate">DOMException: Value not transferable</code> - yet <code class="notranslate">const tmp = new Uint8Array(0); w.postMessage({ tmp }, [ ]);</code> succeeds.</p>
<p dir="auto">There is a related issue <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="740362148" data-permission-text="Title is private" data-url="https://github.com/denoland/deno/issues/8341" data-hovercard-type="issue" data-hovercard-url="/denoland/deno/issues/8341/hovercard" href="https://github.com/denoland/deno/issues/8341">#8341</a>, but it's far more broad - this issue is requesting only ArrayBuffer support, which is part of the spec all browsers implement.</p>
<p dir="auto">Related to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="627697230" data-permission-text="Title is private" data-url="https://github.com/denoland/deno/issues/5965" data-hovercard-type="issue" data-hovercard-url="/denoland/deno/issues/5965/hovercard" href="https://github.com/denoland/deno/issues/5965">#5965</a> (and possibly others)</p>
<p dir="auto">It would be really nice if resources could be Transferable between web workers. This would allow for proper multi-threading for HTTP and WebSocket servers.</p>
<p dir="auto">This can provide multiple benefits:</p>
<ul dir="auto">
<li>Isolated code exposure.<br>
If someone finds a exploit it has a lower likelihood of affecting the entire server, only the worker it was executed on.</li>
<li>Load Balancing.<br>
This allows for balancing across all cores. This could be useful in a number of situations. Now obviously you could just make a new worker for each request and then delete the worker upon completion, but it may be easier conceptually for a programmer to just transfer the connection.</li>
<li>Fault Tolerance.<br>
You can use workers similar to Erlang for fault tolerance. It's easy enough to ensure workers are alive with heartbeats and if they are not you can kill them and re-instate. Would that kick any WebSockets (or any other connection)? Yes. But it is probably better to kick 10% of the server intentionally then for the server to kick 100% due to lag.</li>
</ul>
<p dir="auto">There are probably others but those are the reasons I can think of.</p>
<p dir="auto">This is probably not high up on the priority board, but it would be very nice if only for the use case of WebSockets.</p>