Communication between workers/windows via Streams API

[tyoshino]

/cc @sicking @domenic

A separate thread to continue discussion started at #97 (comment).

[tyoshino]

We've finalized the ReadableStream. Let's investigate the plans again based on the up-to-date ReadableStream design.

The 2 plans proposed are:

• (a) just allow postMessage()-ing ReadableStream
• (b) have a method to create a ReadableStream (WritableStream) to the caller and given the destination worker a WritableStream (ReadableStream) connected with each other

The key difference between them is whether the initiator creates/sees the stream for the peer or not.

(a) has the following topics to solve

• how to neuter the ReadableStream on the original thread
• whether we should postMessage()-ing a reader or a stream or both
• how much of the logic (ReadableStream, ReadableStreamDefaultController, ReadableStreamDefaultReader) should stay in the original thread

Because of these reasons, I proposed (b).

Regarding the 3rd point, I think it's no longer problematic. We need to fail it when chunks and an error object passed to controller.error() are not structured clonable, but except for them, ReadableStream class itself doesn't hold anything externally given. Queuing strategy and underlying source logic are now held by the ReadableStreamDefaultController instance. So, we need to neuter (public interface part of. if difficult, maybe just error it) the ReadableStream in the original worker, create a ReadableStream in the destination worker, connect them by some mechanism to transfer the protocol between the newly created ReadableStream and ReadableStreamDefaultController (with structure cloning).

We need to investigate pipeTo() optimization story before moving forward though. #359

[wanderview]

I feel kind of strongly we should just allow postMessage() of the ReadableStream. I thought we had preliminary agreement to this affect in #276.

If someone wants a WritableStream they should be able to create an identity transform, write to it, and then postMessage() the readable side.

I still like just requiring postMessage() to lock the ReadableStream and then drain the underlying source as mentioned in:

#276 (comment)

This lets the browser grab a c++ underlying source and optimize off thread, but also works for js underlying sources. Interposing a writable step seems like it would make this harder, not easier.

[wanderview]

Sorry, I see your last comment in #276 now. Maybe we have more agreement than I realized.

[domenic]

I think both plans are valuable, but we've heard several times from multiple people at Mozilla that plan (a) is something they are very interested in, so we should probably prioritize it higher. I think we're in agreement on that. And as @wanderview says there's an easy polyfill of (b) on top of (a).

how to neuter the ReadableStream on the original thread

I think just locking it is enough of a neuter. We never need to unlock it either IMO.

whether we should postMessage()-ing a reader or a stream or both

Definitely the stream, as that allows the browser to grab a lock.

[isonmad]

I think just locking it is enough of a neuter. We never need to unlock it either IMO.

What about if you postMessage a stream to a worker, and the worker postMessages the same stream back. Is it the same stream and the original stream gets unlocked, or is it a new object?

[domenic]

That would be a new object, just like when you postMessage any other non-primitive back and forth.

[isonmad]

Actually, where should the error-checking be for when someone further up the pipe chain enqueues chunks that contain things which can't be structured-cloned?

Would there be a third type besides default and "bytes", which will throw a TypeError if you try to controller.enqueue such a chunk, like how ReadableByteStreamController throws? And only that type of stream and byte streams are transferable?

[domenic]

Actually, where should the error-checking be for when someone further up the pipe chain enqueues chunks that contain things which can't be structured-cloned?

It's a good question. I think what would happen is that, as the browser reads the chunks in the background, it tries to structured clone. Any errors go to "report the exception" (i.e. fire an error event on the global scope; show up in the console). At that point we probably cancel the source readable stream, and make the readable stream on the other side of the boundary error.

Would there be a third type besides default and "bytes", which will throw a TypeError if you try to controller.enqueue such a chunk, like how ReadableByteStreamController throws? And only that type of stream and byte streams are transferable?

That seems over-restrictive, and not really necessary. Also you can't really tell if something is cloneable until you try to clone it (e.g. it may have a throwing getter property). So we couldn't really perform this check until we're ready to do the clone/transfer.

---

The larger issue this might be considered blocked on is whatwg/html#935; see in particular my comment whatwg/html#935 (comment).

[isonmad]

you can't really tell if something is cloneable until you try to clone it (e.g. it may have a throwing getter property). So we couldn't really perform this check until we're ready to do the clone/transfer.

Is cloning synchronously on enqueue, instead of on dequeue, not feasible/performant? I guess the queue has to stay in the underlyingSource's thread so that desiredSize is always known synchronously, but can you not serialize on enqueue, and deserialize on dequeue?

Actually I always wondered why structured-clone isn't ever exposed as an API to javascript. Does any implementation of it exist outside of the engines themselves? realistic-structured-clone tries but it says it's really incomplete (can't handle Map, Set, ArrayBuffer, etc).