Perform WebCrypto WebWorker operations *synchronously* on the WebWorker thread |
||||
Issue descriptionCurrently all WebCrypto operations are posted to a single background thread. This is a reasonable tradeoff when using window.crypto.subtle: (a) it avoids blocking the main script thread on slow crypto operations (b) we don't completely saturate the CPU with crypto operations (threadpool of size 1) However this is limiting for consumers that DO want to saturate all the cores to maximize throughput of crypto operations. For more discussion see: https://bugs.chromium.org/p/chromium/issues/detail?id=449009#c11 Solution: Do operations synchronously when run from WebWorker threads. ----- Pros: ----- * This gives developers full control on how to parallelize crypto operations by spawning WebWorker threads. If you need throughput you can achieve it. If you don't care, then using from the main thread optimizes for responsiveness instead. * The semantics of the WebCrypto API are not violated (async API). * Doesn't rely on heuristics or separate threadpools -- the level of parallelization is not a surprise for consumers. * WebWorkers are the platform's answer to parallelization. No need to invent something new for WebCrypto if that can be leveraged. * If don't need to support completion from background thread --> WebWorker thread can simplify some very gnarly code that works around thread-unsafe blink refcounted objects + indeterminate lifetime of WebWorker threads for Promise completion. ----- Cons: ----- * Not intuitive. Developers will need to be told this is how things work in order to leverage it. * Can't queue webcrypto operations from WebWorker threads, since will always perform synchronously. Really this is a hack, and synchronous operation should be something explicitly selected through the API, and available only on worker threads (however a synchronous API was rejected by the working group). * ServiceWorkers are also WebWorkers, and would inherit this behavior. Not sure what the best policy is for them, but would not want to special case Service workers (since then can't simplify the code).
,
May 26 2016
Adding Alex and Domenic as FYI & platform sanity checks.
,
May 26 2016
Woah. I'd never considered something like this, i.e. keeping the async API form but actually doing all the work on the same thread, as a possibility. My immediate worry is that some workers, such as service workers or shared workers, would be majorly harmed by this, since they need to stay responsive to incoming events and potentially process many things in parallel. Similarly any worker which plans to receive messages using onmessage. I guess I'd prefer to figure out an API surface that explicitly optimizes for throughput instead of responsiveness, and even one that could potentially be used from the main thread. I disagree with the idea that web workers are the platform's answer to parallelization; in general async APIs are the biggest part of that story, with web workers being a blunt instrument.
,
May 26 2016
Thanks for the feedback Dominic! The issue being faced right now is: * The WebCrypto API does not have a way to indicate intended queueuing/execution behavior when starting asynchronous tasks. * Crypto operations are slow. Some users have complained about the inability to achieve high throughput of operations, as all operations are scheduled to a single background thread. I am not sure how best to overcome this -- the best idea I had so far was the "synchronous on webworker" model. Another proposal was to simply saturate the CPU with crypto operations, always. I really don't like this though. That makes no distinction between the intent for concurrency (for which queuing is fine) vs parallelizing execution for higher throughput. It also has some undesirable implementation consequences. I will discuss this with the WG, but I don't expect any changes will be taken to the API for this version anyway.
,
May 26 2016
Another idea could be to use an independent background thread *per* WebWorker. So tasks would still be executed asynchronously for WebWorkers, but using an independent thread. This still provides a way to increase parallelization of WebCrypto by using WebWorker threads, but without making it synchronous either. This could be a workable compromise, but at the cost of an extra thread per WebWorker. I don't know enough about the current threading model of WebWorkers -- do we already have such a companion thread used for background processing?
,
Jul 14 2016
No plans to do the original proposal given the concerns. Will try to have the TaskScheduler solve this (issue 623700). Failing that will re-visit comment #5.
,
Nov 7 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by eroman@chromium.org
, May 26 2016