Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align WritableStream structure with ReadableStream structure #488

Closed
wants to merge 19 commits into from

Conversation

tyoshino
Copy link
Member

@tyoshino tyoshino commented Aug 1, 2016

  • Add WritableStreamDefaultWriter
  • Add WritableStreamDefaultController
  • Add lock related methods
  • Update reader.pipeTo() to use the new WritableStream classes
  • Refine reader.pipeTo()'s error handling
  • Update TransformStream to use the new WritableStream classes
  • Refine TransformStream's error handling
  • Document the difference between ReadableStream's locking (releaseLock()) and WritableStream's one

- Add WritableStreamDefaultWriter
- Add WritableStreamDefaultController
- Add lock related methods
- Update reader.pipeTo() to use the new WritableStream classes
@tyoshino
Copy link
Member Author

tyoshino commented Aug 1, 2016

Squashed and rebased version of #462.

@tyoshino
Copy link
Member Author

tyoshino commented Aug 1, 2016

I inserted a lot of logs this time for debugging pipeTo(). I'd like to leave some or all of them in the reference impl for debugging in the future. Do you have any opinion about that, Domenic?

@tyoshino
Copy link
Member Author

tyoshino commented Aug 1, 2016

In rewriting pipeTo() algorithm, I felt that it's good if we apply some convention to variable naming to distinguish variables local to the inner functions and ones of pipeTo() like how we're distinguishing internal slots and local variables. I'm tentatively prefixing them with _.

@domenic
Copy link
Member

domenic commented Aug 1, 2016

I'd like to leave some or all of them in the reference impl for debugging in the future. Do you have any opinion about that, Domenic?

I think we should at least comment them out when committing to the repo. In the future we could investigate a logging framework that allows us to toggle them on and off with environment variables, like https://www.npmjs.com/package/debug maybe.


this._readyPromise = Promise.resolve(undefined);
this._readyPromise_resolve = null;
this._writeRequests = [];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a comment that these are kept here instead of on the writer because we want to allow multiple queued up writes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed by e57e25e

I'm not sure if it's what you meant. Please take a look again.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that is exactly what I meant, sorry, I was pretty unclear.

}

if (IsWritableStreamLocked(this) === true) {
return Promise.reject(new TypeError('Cannot abort a stream that already has a reader'));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/reader/writer

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed by e57e25e


return undefined;
WritableStreamFulfillWriteRequest(stream);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not fulfill the write request normally? Why is the last write request special?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_writeRequests now holds both pending write and pending close. That's why we're calling this here.

@domenic
Copy link
Member

domenic commented Aug 1, 2016

Review finished :). Seems like you've got most of my comments already. Big ones are waitForDesiredSize (#488 (comment)) and the different states (#488 (comment)).

domenic pushed a commit that referenced this pull request Aug 4, 2016
In general we are loathe to introduce this kind of departure from the spec. However, it improves our ability to run the tests quickly by a very large factor. See the context at #488 (comment).
@domenic
Copy link
Member

domenic commented Aug 4, 2016

I think this is ready! What about you?

@domenic
Copy link
Member

domenic commented Aug 4, 2016

Draft commit message:

Add locking and precise flow control to WritableStream

This fixes #319 (by adding locking and the concept of a writable stream writer) and fixes #318 (by adding precise flow control via the writer.desiredSize property). The structure parallels that introduced for ReadableStream, including the introduction of a controller class.

The infrastructure is set up to allow the future introduction of different types of writable streams (with corresponding new controllers and writers).

With this in place, the public API for writable streams is almost stable; the remaining issue is whether writers should have a ready promise, or a waitForDesiredSize() method which could in the future be customized by passing an argument (see discussions in #318).

The reference implementation's pipeTo and transform stream code has been updated, and all the tests pass, but they haven't been put in the spec yet, as their design is not yet finalized (but is much closer to now that they have a more stable WritableStream foundation).

Merge at will!

@tyoshino
Copy link
Member Author

tyoshino commented Aug 4, 2016

Merged as 5a27534

@tyoshino
Copy link
Member Author

tyoshino commented Aug 4, 2016

We may want to create ReadableStreamDefaultControllerErrorIfNeeded so that readable and writable are more parallel. I noticed the spec always does a state check for readable streams in the same way.

Done by 28c20b1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

2 participants