I guess a good rule of thumb is “if it blocks your CPU core, it’s not async”? That principle would make I/O and WebGL async but crypto (AES-NI) sync.
-
-
Blocking the CPU core doesn't mean it needs to block rendering, but when we give main-thread JS sync APIs, that's what folks do. I guess another point in the design space would be to make crypto worker-only?
2 replies 0 retweets 1 like -
Although really I think the line might be between sync hashes & symmetric crypto, and async asymmetric crypto. I want some principle based on third-world phones, though, before really endorsing that position.
1 reply 0 retweets 0 likes -
Note we do a lot of asymmetric crypto sync in Chrome too. You want to look at overall system behavior, not just avoiding misuse. Async for medium-cost CPU-bound low-level primitives isn't great. Sync + worker-only seems to satisfy both better.
1 reply 0 retweets 2 likes -
Replying to @davidben__ @jyasskin and
worker seems like a good compromise. I could imagine a future where if you spend more than a few frames without returning to event loop your script dies.
1 reply 0 retweets 0 likes -
-
Replying to @pcwalton @davidben__ and
maybe start it off opt-in? So preempt long running event handlers and throw some exception?
1 reply 0 retweets 0 likes -
Replying to @mik235 @davidben__ and
I mean, we already have the slow script dialog. I guess we could tweak the timeout and/or make it user-configurable.
1 reply 0 retweets 0 likes -
That is *really* shifting responsibility to the wrong party. See the priority of constituencies.
1 reply 0 retweets 0 likes
It’s not a proposal. I’m just saying that killing slow scripts isn’t web compatible.
-
-
Ah, right. We’re on the same page, then.
0 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.