Re: [whatwg/streams] Transferable streams: the double transfer problem (#1063)

Here's a sketch of an approach which reconciles the atomic nature of transfer with the asynchronous nature of streams.

I'm going to talk about the WritableStream case because I think it is the harder of the two.

1. We give up the nice abstraction of the "cross-realm identity transform" because it makes the following stuff harder. Instead we have separate transfer logic for ReadableStream and WritableStream.
2. We have a stream with the underlying sink in the original realm O and the transferred writable stream in realm A.
3. We want to transfer from realm A to realm B.
4. The atomic part of the transfer works much the same as before (it's a bit ugly because we can no longer use the piping logic to synchronise the states).
5. The new WritableStream sends a message back to A asking for a new message pipe. It starts queuing writes rather than sending them to A (this may result in backpressure being applied).
6. The WritableStream in A waits until its write queue is empty, and then forwards the "new message pipe request" back to O.
7. O constructs a new message pipe and sends it to A, which passes it on to B.
8. B starts sending writes down the new message pipe directly to O.
9. B sends a message to A to close itself.

After step 9, realm A has been "unhooked" and can safely be destroyed.

There can be an arbitrary delay for queued writes to complete before A is "unhooked". Maybe we can force the queued chunks from A into O's queue by ignoring backpressure to make this delay as short as possible?

-- 
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/1063#issuecomment-970222762