The design was made so that the promises could be synchronously resolved and async/await would handle any other grossness
-
-
I'm hugely skeptical of the "wasm justifies synchronous interfaces for everything" approach. Didn't work for IDB + workers, don't see why this is different
4 replies 0 retweets 5 likes -
Replying to @slightlylate @sleevi_ and
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.
1 reply 0 retweets 2 likes -
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 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 @davidben__ and
Also, "and slow" is contextual enough to be meaningless in the general API design sense. Do I assume rAF-speed EBC operations? With how many cores? Are HSMs consulted?
2 replies 0 retweets 1 like
Do you want every application that uses cryptography that's compiled to wasm to use unsafe implementations of the crypto? If not, a synchronous API for most operations is needed. See https://github.com/briansmith/ring/issues/657 … for why I bring it up. Lots of private requests for wasm port too.
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.