Re: [whatwg/streams] Communication between workers/windows via Streams API (#244)

> For (3), I'm assuming the protocol would be a function of some sort. (Either one that returns the transferable parts, or one that somehow "does the transfer".) Doesn't that reintroduce
> 
> > The transfer() function cannot itself be transferred, which means that if a stream is transferred twice it will lose its ability to transfer chunks.
> 
> to (3) as well?

I've been wondering whether a meta-protocol as simple as

`[Symbol.transferKeys] : ['value']`

could work. For a nested object you'd end up with something like

```javascript
{
  key: 'outer',
  value: {
    label: 'car',
    data: new Uint8Array([1, 2]),
    [Symbol.transferKeys]: ['data']
  },
  [Symbol.transferKeys]: ['value']
}
```

It seems overly simplistic, but I haven't come up with a case where it wouldn't work yet.

> To me, the transfer-twice problem is the worst issue here. Everything else in the disadvantages columns seems solvable.

Thinking about it further, I realised it can be a problem even with a single transfer. Consider these steps:
1. Create a WritableStream on the main thread, with `transfer(chunk) { return [chunk.value]; }` in its strategy.
2. Transfer it to a Worker
3. Call `ws.getWriter().write({value: new Uint8Array([1, 2])})` in the Worker.

The intent is that `value` gets transferred rather than copied, but since the `transfer()` function cannot be executed in the Worker, `value` has to be copied to transfer the chunk to the main thread.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/244#issuecomment-383787420