Synchronous queue draining for WritableStream

[tyoshino]

A WritableStream invokes its underlying sink's write() method for each chunk in its queue. This completes only asynchronously on invocation of the fulfillment callback set to the promise returned by the write() call. This means that one microtask is required to process each chunk.

We could change this to allow for synchronous draining by introducing an interface similar to the byobRequest interface we've adopted for responding to BYOB reading in the underlying source of ReadableStream.

It'll be like:

• when a new chunk is enqueued, write() (or could be renamed to push()) is invoked to notify the sink of that there're some chunks available for processing (redundant invocation is still prevented by the _writing flag).
• WritableStreamDefaultController has a getter named writeRequest() which has get chunk() and ack() method.
• Calling ack() tells the WritableStream to fulfill the promise returned on write() call on the WritableStream.
• Once ack() is called, writeRequest() is updated to represent the next chunk in the queue. If there's no chunk, it returns undefined.

[tyoshino]

Hmm. WritableStream.write() synchronously invokes underlyingSink.write(). With this optimization, sequential multiple write() calls are processed by:

• ws.write() -> sink.write()
• ws.write(), ws.write(), ... -> pending until the fulfillment callback is invoked
• sink.write() processes chunks enqueued by the 2nd and later ws.write() calls

Looks weird. But there's similar behavior in ReadableStream too? pull is invoked sync to read() and we can call rscontroller.enqueue() multiple times synchronously but they're delivered to the data consumer in async manner.

[domenic]

I am not too worried about the microtask delay; I feel like we discovered a while ago that wasn't a very important part of things. So I think for the default controller the current design is good.

However, I do think we should consider "BYOB" writable streams (I guess in this case it's "keep your own buffer"? KYOB?) with an efficient interface. I'm not sure exactly what that looks like or how it works. I guess that ties in to #329 and #325.

[domenic]

Let's close this as I think our current design is pretty good.

[tyoshino]

OK. Thanks