-
Notifications
You must be signed in to change notification settings - Fork 163
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
Port locking infrastructure to writable streams #319
Comments
Yeah, pipeTo etc. all belongs to the readable side. What do you mean by pass-through? Keeping a method also on the WritableStream? As you just said, I also think we should basically limit them to WritableStreamWriter as much as possible.
Maybe you meant abort() and close(). |
I mean, like we do for ReadableStream.prototype.cancel, have versions of them on the WritableStream which throw if the WritableStream is locked.
Yes, editing OP. |
OK. I slightly prefer not putting them on WritableStream. The same about But given that we have |
Plan: class WritableStream {
constructor(underlyingSink = {}, { size, highWaterMark = 0 } = {})
get locked()
getWriter()
abort(reason)
close()
}
class WritableStreamWriter {
constructor(stream)
get closed()
get ready() // see #318
abort(reason)
close()
releaseLock()
write(chunk)
} No need for WritableStreamController. Can eliminate |
PR created: #462 |
Writable streams need a similar way of being locked for exclusive writing, as readable streams do with their readers. This is notably crucial for off-main-thread piping (#97).
One problem that immediately presents itself, looking at the current list of writable stream properties and methods (closed/ready/state/abort()/close()/write()), is that pretty much all of them belong on the writer. Does that mean writable streams themselves become empty objects with getWriter() methods!?
I guess we could add a few pass-throughs (like ReadableStream.prototype.cancel acquiring, then releasing, a reader). Do we just add pass-through for everything? Well, probably not for ready/state/closed at least, as that causes problems. But if all we have is abort()/close()/write() passthroughs, doesn't that encourage the bad practice of ignoring backpressure signals? Maybe just abort() and close()?
The text was updated successfully, but these errors were encountered: