I/O+bound isn't different to CPU-bound when responsiveness is at risk. Environments without threading rely on tasks deferring for responsiveness.
-
-
I suppose I could be convinced having a sync crypto interface in a worker makes sense, though it doesn't make sense to do any of that work on the same thread that does webgl or the UI main thread.
-
Right, just like you wouldn't allow WebAssembly to run on those threads.
End of conversation
New conversation -
-
-
What apps? There isn't a sync socket API in the web, or even a low level one to do such a thing. Super interested in your app, how are you using BoringSSL on the web?
-
We can't use BoringSSL on the web because (1) it isn't safe to compile its C code to wasm because wasm doesn't guarantee safety w.r.t. side channels, and (2) BoringSSL's API is sync, so it can't implement its API on top of WebCrypto because WebCrypto is async.
End of conversation
New conversation -
-
-
I'm also skeptical that success lies in "porting existing apps to webassembly". WASM is a great technology, and a useful tool, but you still need to leverage the platform for what it does well: being async, loading fast over a network, being SLICE:https://www.google.com/amp/s/paul.kinlan.me/amp/slice-the-web/ …
-
Right. If we had a way to mark workers as being "input sinks" and turning off all sync APIs for them, I'd feel better about allowing them.
-
I think there is a clear misunderstanding here as to what these operations actually are. Twitter is not a good medium to clear this up. Let's get on a VC when I'm back at work and not dealing with a move.
-
Sure thing. Very excited to learn more about your use cases!
End of conversation
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.