Validate queueing strategies are sufficiently powerful #119
Comments
This was referenced Jun 17, 2014
|
Oops. I realized there's a bug in the current spec's strategy usage: #121. Will update the "current spec" section once it is fixed. |
|
Bug fixed; let the discussion resume! |
|
Great progress, Domenic! Sorry for delay but I'm taking a look at the new revision. Let me reply to each sub-issue separately.
|
|
|
tyoshino
added a commit
to tyoshino/streams
that referenced
this issue
Jul 23, 2014
Also adds code to handle an error in needsMore Issue: whatwg#119 (comment)
tyoshino
added a commit
that referenced
this issue
Jul 24, 2014
Also adds code to handle an error in needsMore Issue: #119 (comment)
domenic
added a commit
that referenced
this issue
Apr 7, 2015
This changes the way queuing strategies work, and how backpressure signals are propagated from readable stream controllers, in the service of giving more precise information to be used for flow control. Queuing strategies now explicitly embrace the concept of "high water mark," instead of having a general `shouldApplyBackpressure` method. This allows us to calculate the "desired size to fill a stream's internal queue", and expose it as a `desiredSize` property on the readable stream controller. The algorithm for determining whether to call pull was updated, per #301 (comment), to no longer be based on the boolean "should apply backpressure" logic. The logic is now to avoid calling pull if desired size is <=0 (unless there are pending read requests, in which case pull should be called anyway). In particular, this modifies test expectations in some cases where start enqueues chunks; after this change pull is no longer automatically called after start in such cases. The API changes in detail: - The readable and writable stream constructors now validate the passed queuing strategy and extract its values. - Queuing strategies are no longer treated as instances of classes, but instead as property bags. (That is, we no longer "invoke" `strategy.size`, but instead simply extract the `size` function from strategy and "call" it.) - The built-in queuing strategies no longer validate the passed high water mark argument and store it in an internal slot. Instead they simply define a data property on themselves whose value is the passed high water mark. - Queuing strategies no longer have `shouldApplyBackpressure` methods. - `ReadableStreamController.prototype` gained a `desiredSize` getter. - `ReadableStreamController.prototype.enqueue` (and EnqueueInReadableStream) no longer return a boolean to signal backpressure; instread consult `controller.desiredSize` for more precise information. The correspondence is: `enqueueReturnValue === controller.desiredSize > 0`. Note that writable streams do not yet expose the desired size. We expect to do that later, probably in conjunction with related changes. For now, they translate the desired size into a boolean distinction between "waiting" and "writable", giving the same results as before. Fixes #301. Addresses half of #119.
domenic
added a commit
that referenced
this issue
Apr 10, 2015
This changes the way queuing strategies work, and how backpressure signals are propagated from readable stream controllers, in the service of giving more precise information to be used for flow control. Queuing strategies now explicitly embrace the concept of "high water mark," instead of having a general `shouldApplyBackpressure` method. This allows us to calculate the "desired size to fill a stream's internal queue", and expose it as a `desiredSize` property on the readable stream controller. The algorithm for determining whether to call pull was updated, per #301 (comment), to no longer be based on the boolean "should apply backpressure" logic. The logic is now to avoid calling pull if desired size is <=0 (unless there are pending read requests, in which case pull should be called anyway). In particular, this modifies test expectations in some cases where start enqueues chunks; after this change pull is no longer automatically called after start in such cases. The API changes in detail: - The readable and writable stream constructors now validate the passed queuing strategy and extract its values. - Queuing strategies are no longer treated as instances of classes, but instead as property bags. (That is, we no longer "invoke" `strategy.size`, but instead simply extract the `size` function from strategy and "call" it.) - The built-in queuing strategies no longer validate the passed high water mark argument and store it in an internal slot. Instead they simply define a data property on themselves whose value is the passed high water mark. - Queuing strategies no longer have `shouldApplyBackpressure` methods. - `ReadableStreamController.prototype` gained a `desiredSize` getter. - `ReadableStreamController.prototype.enqueue` (and EnqueueInReadableStream) no longer return a boolean to signal backpressure; instread consult `controller.desiredSize` for more precise information. The correspondence is: `enqueueReturnValue === controller.desiredSize > 0`. Note that writable streams do not yet expose the desired size. We expect to do that later, probably in conjunction with related changes. For now, they translate the desired size into a boolean distinction between "waiting" and "writable", giving the same results as before. Fixes #301. Addresses half of #119.
domenic
added a commit
that referenced
this issue
Apr 14, 2015
This changes the way queuing strategies work, and how backpressure signals are propagated from readable stream controllers, in the service of giving more precise information to be used for flow control. Queuing strategies now explicitly embrace the concept of "high water mark," instead of having a general `shouldApplyBackpressure` method. This allows us to calculate the "desired size to fill a stream's internal queue", and expose it as a `desiredSize` property on the readable stream controller. The algorithm for determining whether to call pull was updated, per #301 (comment), to no longer be based on the boolean "should apply backpressure" logic. The logic is now to avoid calling pull if desired size is <=0 (unless there are pending read requests, in which case pull should be called anyway). In particular, this modifies test expectations in some cases where start enqueues chunks; after this change pull is no longer automatically called after start in such cases. The API changes in detail: - The readable and writable stream constructors now validate the passed queuing strategy and extract its values. - Queuing strategies are no longer treated as instances of classes, but instead as property bags. (That is, we no longer "invoke" `strategy.size`, but instead simply extract the `size` function from strategy and "call" it.) - The built-in queuing strategies no longer validate the passed high water mark argument and store it in an internal slot. Instead they simply define a data property on themselves whose value is the passed high water mark. - Queuing strategies no longer have `shouldApplyBackpressure` methods. - `ReadableStreamController.prototype` gained a `desiredSize` getter. - `ReadableStreamController.prototype.enqueue` (and EnqueueInReadableStream) no longer return a boolean to signal backpressure; instread consult `controller.desiredSize` for more precise information. The correspondence is: `enqueueReturnValue === controller.desiredSize > 0`. Note that writable streams do not yet expose the desired size. We expect to do that later, probably in conjunction with related changes. For now, they translate the desired size into a boolean distinction between "waiting" and "writable", giving the same results as before. Fixes #301. Addresses half of #119.
domenic
added a commit
that referenced
this issue
Apr 15, 2015
This changes the way queuing strategies work, and how backpressure signals are propagated from readable stream controllers, in the service of giving more precise information to be used for flow control. Queuing strategies now explicitly embrace the concept of "high water mark," instead of having a general `shouldApplyBackpressure` method. This allows us to calculate the "desired size to fill a stream's internal queue", and expose it as a `desiredSize` property on the readable stream controller. The algorithm for determining whether to call pull was updated, per #301 (comment), to no longer be based on the boolean "should apply backpressure" logic. The logic is now to avoid calling pull if desired size is <=0 (unless there are pending read requests, in which case pull should be called anyway). In particular, this modifies test expectations in some cases where start enqueues chunks; after this change pull is no longer automatically called after start in such cases. The API changes in detail: - The readable and writable stream constructors now validate the passed queuing strategy and extract its values. - Queuing strategies are no longer treated as instances of classes, but instead as property bags. (That is, we no longer "invoke" `strategy.size`, but instead simply extract the `size` function from strategy and "call" it.) - The built-in queuing strategies no longer validate the passed high water mark argument and store it in an internal slot. Instead they simply define a data property on themselves whose value is the passed high water mark. - Queuing strategies no longer have `shouldApplyBackpressure` methods. - `ReadableStreamController.prototype` gained a `desiredSize` getter. - `ReadableStreamController.prototype.enqueue` (and EnqueueInReadableStream) no longer return a boolean to signal backpressure; instread consult `controller.desiredSize` for more precise information. The correspondence is: `enqueueReturnValue === controller.desiredSize > 0`. Note that writable streams do not yet expose the desired size. We expect to do that later, probably in conjunction with related changes. For now, they translate the desired size into a boolean distinction between "waiting" and "writable", giving the same results as before. Fixes #301. Addresses half of #119.
domenic
added a commit
that referenced
this issue
Apr 20, 2015
This changes the way queuing strategies work, and how backpressure signals are propagated from readable stream controllers, in the service of giving more precise information to be used for flow control. Queuing strategies now explicitly embrace the concept of "high water mark," instead of having a general `shouldApplyBackpressure` method. This allows us to calculate the "desired size to fill a stream's internal queue", and expose it as a `desiredSize` property on the readable stream controller. The algorithm for determining whether to call pull was updated, per #301 (comment), to no longer be based on the boolean "should apply backpressure" logic. The logic is now to avoid calling pull if desired size is <=0 (unless there are pending read requests, in which case pull should be called anyway). In particular, this modifies test expectations in some cases where start enqueues chunks; after this change pull is no longer automatically called after start in such cases. The API changes in detail: - The readable and writable stream constructors now validate the passed queuing strategy and extract its values. - Queuing strategies are no longer treated as instances of classes, but instead as property bags. (That is, we no longer "invoke" `strategy.size`, but instead simply extract the `size` function from strategy and "call" it.) - The built-in queuing strategies no longer validate the passed high water mark argument and store it in an internal slot. Instead they simply define a data property on themselves whose value is the passed high water mark. - Queuing strategies no longer have `shouldApplyBackpressure` methods. - `ReadableStreamController.prototype` gained a `desiredSize` getter. - `ReadableStreamController.prototype.enqueue` (and EnqueueInReadableStream) no longer return a boolean to signal backpressure; instread consult `controller.desiredSize` for more precise information. The correspondence is: `enqueueReturnValue === controller.desiredSize > 0`. Note that writable streams do not yet expose the desired size. We expect to do that later, probably in conjunction with related changes. For now, they translate the desired size into a boolean distinction between "waiting" and "writable", giving the same results as before. Fixes #301. Addresses half of #119.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm going to consolidate a few threads into this one.
Current Spec
The current spec is largely based around Node's high water marks, providing I believe the exact same amount of power, although in a different API package.
ReadableStream
strategy.size, is added to the total queue size."readable", consultstrategy.needsMore(currentTotalSize), to determine the return value ofenqueue(chunk).rs.read().WritableStream
[[syncStateWithQueue]]()adjustsws.stateto be either"waiting"or"writable", depending:strategy.needsMore(totalCurrentSize); if the return value is truthy, the stream becomes"writable"; if falsy, the stream becomes"waiting".Ideas and Help Wanted
@tyoshino previously mentioned, in #76 and summarized in #24 (comment) (with some substitutions for the new terminology):
@tyoshino, I am curious whether you think the current proposal accomplishes this or not? I suspect not. In which case, what would help? I think I got confused in the various previous threads.
In #76 the thread ended with:
This sounds more different than the current proposal, and more along the lines of things that came up while discussing with @slightlyoff and @willchan. It might tie into #111, which will probably be in a separate BinaryStream subclass, but we should be sure the base interface exposes enough information or hooks too.
The text was updated successfully, but these errors were encountered: