Have you weighed in on the OffscreenCanvas.commit() questions? They're designing around a Wasm model that never yields. Now, it'd be totally possible to provide a way to read Promises values synchronously, so that we don't need to dupicate every API.
-
-
I'm deeply uncomfortable about that design. The more I look, the more it worries me. Will discuss with those folks shortly.
1 reply 0 retweets 4 likes -
Replying to @slightlylate @sleevi_ and
We may need a TAG statement that this never-yielding model is something the web just shouldn't try to support. Otherwise folks will keep hearing requests for it and keep trying to support it.
2 replies 0 retweets 3 likes -
Replying to @jyasskin @slightlylate and
It's there a summary of why it's universally bad? We might need it for some kind of bytestorage API. Something mmap-like.
2 replies 0 retweets 1 like -
Replying to @jaffathecake @jyasskin and
Much of WebCrypto has no business being asynchronous. Promises and friends make sense for IO-bound operations, while crypto is CPU-bound. Most of it is also quite fast, to the point that the promise machinery costs more than the operation itself.
2 replies 0 retweets 3 likes -
Replying to @davidben__ @jaffathecake and
If it's CPU-bound and slow, that probably also justifies promises + worker pool (RSA keygen definitely, maybe some other asymmetric operations), but the symmetric ops should have been synchronous.
1 reply 0 retweets 1 like -
Replying to @davidben__ @jaffathecake and
I/O+bound isn't different to CPU-bound when responsiveness is at risk. Environments without threading rely on tasks deferring for responsiveness.
2 replies 0 retweets 2 likes -
Replying to @slightlylate @jaffathecake and
Which is why I mentioned symmetric vs asymmetric operations. Computing a hash is not a responsiveness risk. We're talking operations where we look at avoiding malloc because it's on the radar at this scale.
1 reply 0 retweets 3 likes -
Replying to @davidben__ @slightlylate and
… the TAG should probably give some guidance about when a CPU-bound operation takes long enough to make it promise-based. e.g. Hashes and AES handle 1MB in about 1ms, which is probably fine to block the main thread, but we also just added img.decode() because images take longer.
3 replies 0 retweets 2 likes -
Replying to @jyasskin @slightlylate and
(Not sure yet how much I believe this claim) Perhaps CPU-bound alone justifies sync, but maybe not callable on UI thread. You won't do better than a background thread, be it app- or browser-owned. Former is more flexible and inherits existing DoS limits. Latter needs custom limit
1 reply 0 retweets 1 like
"UI thread" is the sort of assumption in system design that frequently defeats responsiveness (while improving throughput). Most engineers live in someone else's framework; also responsiveness is king on the client side.
-
-
Replying to @BRIAN_____ @davidben__ and
I hear compilers are "a thing" these days.
2 replies 0 retweets 4 likes - 9 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.