-
Notifications
You must be signed in to change notification settings - Fork 162
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
Can pipeTo() be synchronous? #1243
Comments
I discussed this a bit with Adam in person, but for the record, my opinions are:
So my vote would be for ensuring that writes do not occur synchronously, and are at least delayed by a queued microtask. |
Okay. If there are no conflicting opinions then @nidhijaju or I will write a PR to prohibit synchronous behaviour. |
Has this happened? I found Gecko is behaving synchronously and intend to write WPT for this. |
Sorry, no, it slipped off my radar. Some WPT would be great! |
Another issue: await Promise.resolve().then(async () => {
let synchronous = false;
let readable = new ReadableStream({
pull() {
synchronous = true;
}
}, { highWaterMark: 0 });
await new Promise(setTimeout); // make sure the stream is started
readable.pipeTo(new WritableStream());
console.log(synchronous);
}); This logs true on Gecko/Blink but false on WebKit. Maybe it's more natural to be synchronous here as Edit: The WPT test for the enqueue issue is landed here web-platform-tests/wpt#39103 |
Previously we considered this kind of thing "acceptable variation". If I recall correctly there was a similar difference between Blink's implementation and the reference implementation. The aim in specifying pipeTo() was to specify a set of constraints, and permit implementations to very within those constraints in order to allow for optimisation. Maybe now we want to be more strict.
Thanks! |
Consider the following code:
true
?true
?true
web-compatible?The text was updated successfully, but these errors were encountered: