It's there a summary of why it's universally bad? We might need it for some kind of bytestorage API. Something mmap-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 4 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 2 likes -
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 2 likes -
Replying to @davidben__ @jyasskin and
"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.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @davidben__ and
Development time is king. Having to rewrite a bunch of synchronous security code just for the web platform because it only has async APIs kills productivity, leads to bad workarounds, and increases the opportunity to make mistakes because one cannot reuse known-good code.
1 reply 0 retweets 1 like -
Replying to @BRIAN_____ @davidben__ and
I hear compilers are "a thing" these days.
3 replies 0 retweets 4 likes
Please talk to the BoringSSL team about this.
-
-
Replying to @BRIAN_____ @slightlylate and0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.
