Bug 146312 - [Streams API] Add support for chunks with customized sizes
Summary: [Streams API] Add support for chunks with customized sizes
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords:
Depends on: 146311
Blocks: 138967
  Show dependency treegraph
 
Reported: 2015-06-25 05:24 PDT by youenn fablet
Modified: 2015-06-28 05:40 PDT (History)
4 users (show)

See Also:


Attachments
Patch (7.02 KB, patch)
2015-06-25 06:22 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
style fix (6.98 KB, patch)
2015-06-25 06:40 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch for landing (6.86 KB, patch)
2015-06-28 04:47 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2015-06-25 05:24:34 PDT
Implement step 5 of https://streams.spec.whatwg.org/#enqueue-in-readable-stream
Comment 1 youenn fablet 2015-06-25 06:22:27 PDT
Created attachment 255549 [details]
Patch
Comment 2 youenn fablet 2015-06-25 06:40:03 PDT
Created attachment 255551 [details]
style fix
Comment 3 Darin Adler 2015-06-27 15:27:59 PDT
Comment on attachment 255551 [details]
style fix

View in context: https://bugs.webkit.org/attachment.cgi?id=255551&action=review

> Source/WebCore/bindings/js/ReadableJSStream.cpp:339
> +    if (state.hadException()) {
> +        storeError(state, state.exception()->value());
> +        return;
> +    }

If we are turning the exception into a stored error, then I assume we don’t want to also leave it in the execution state. Do we have a test covering this?

Seems like this should be doing clearException(). Or we should add a takeException() function that combines fetching the exception with clearing it.

> Source/WebCore/bindings/js/ReadableJSStream.cpp:358
> +    JSValue sizeValue = callFunction(state, m_sizeFunction.get(), jsUndefined(), arguments);
> +
> +    if (state.hadException())
> +        return 0;

I’d leave out these blank lines.

> Source/WebCore/bindings/js/ReadableJSStream.cpp:363
> +    double size = sizeValue.toNumber(&state);
> +
> +    if (state.hadException())
> +        return 0;

Ditto.

> Source/WebCore/bindings/js/ReadableJSStream.cpp:365
> +    if (std::isnan(size) || std::isinf(size)) {

if (!std::isfinite(size)) {

> Source/WebCore/bindings/js/ReadableJSStream.cpp:366
> +        throwVMError(&state, createRangeError(&state, ASCIILiteral("Incorrect double value.")));

I’m not a big fan of these ad hoc error messages. Why in this case do we use the words “Incorrect double value” with a period? We need to share more code so that each bit of JavaScript binding like this doesn’t end up doing things differently than other bindings performing the same operation.

> Source/WebCore/bindings/js/ReadableJSStream.h:82
> +    double chunkSize(JSC::ExecState&, JSC::JSValue);

Because there are side effects, we might want a verb in the name of this function. It’s not just a simple getter because it calls the size function and possibly runs code in the process of converting the value to a number as well.
Comment 4 youenn fablet 2015-06-28 04:39:56 PDT
Comment on attachment 255551 [details]
style fix

View in context: https://bugs.webkit.org/attachment.cgi?id=255551&action=review

>> Source/WebCore/bindings/js/ReadableJSStream.cpp:339
>> +    }
> 
> If we are turning the exception into a stored error, then I assume we don’t want to also leave it in the execution state. Do we have a test covering this?
> 
> Seems like this should be doing clearException(). Or we should add a takeException() function that combines fetching the exception with clearing it.

Test coverage is found in LayoutTests/streams/reference-implementation/bad-strategies.html (e.g. "Readable stream: throwing strategy.size method").
If enqueue is throwing within a start call and start JS callback does not catch it, the constructor will throw. This sounds good.
If enqueue is throwing within a further pull and pull JS callback does not catch it, this will trigger corresponding promise rejection (like read() for instance).

>> Source/WebCore/bindings/js/ReadableJSStream.cpp:358
>> +        return 0;
> 
> I’d leave out these blank lines.

OK

>> Source/WebCore/bindings/js/ReadableJSStream.cpp:363
>> +        return 0;
> 
> Ditto.

OK

>> Source/WebCore/bindings/js/ReadableJSStream.cpp:365
>> +    if (std::isnan(size) || std::isinf(size)) {
> 
> if (!std::isfinite(size)) {

OK

>> Source/WebCore/bindings/js/ReadableJSStream.cpp:366
>> +        throwVMError(&state, createRangeError(&state, ASCIILiteral("Incorrect double value.")));
> 
> I’m not a big fan of these ad hoc error messages. Why in this case do we use the words “Incorrect double value” with a period? We need to share more code so that each bit of JavaScript binding like this doesn’t end up doing things differently than other bindings performing the same operation.

Will remove the ".".
As part of refactoring, I will remove enqueue custom binding once we can use a direct "any->JSC::JSValue" binding rule.
At that time, this exception will be transmitted to binding level using an ExceptionCode.

>> Source/WebCore/bindings/js/ReadableJSStream.h:82
>> +    double chunkSize(JSC::ExecState&, JSC::JSValue);
> 
> Because there are side effects, we might want a verb in the name of this function. It’s not just a simple getter because it calls the size function and possibly runs code in the process of converting the value to a number as well.

Let's rename it to retrieveChunkSize then.
Comment 5 youenn fablet 2015-06-28 04:47:03 PDT
Created attachment 255722 [details]
Patch for landing
Comment 6 WebKit Commit Bot 2015-06-28 05:40:42 PDT
Comment on attachment 255722 [details]
Patch for landing

Clearing flags on attachment: 255722

Committed r186044: <http://trac.webkit.org/changeset/186044>
Comment 7 WebKit Commit Bot 2015-06-28 05:40:46 PDT
All reviewed patches have been landed.  Closing bug.