On 2014-05-13, 11:14 AM, Eli Grey wrote:
On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari <[email protected] <mailto:[email protected]>> wrote:No, you're wrong. An available core is a core which your application can use to run computations on. If another code is already keeping it busy with a higher priority, it's unavailable by definition. Run this code <https://gist.github.com/eligrey/9a48b71b2f5da67b834b> in your browser. All cores are at 100% CPU usage, so clearly by your definition all cores are now "unavailable".
They are unavailable to *all* threads running on your system with a lower priority. (Note that Gecko runs Web Workers with a low priority already, so that they won't affect any of your normal apps, including Firefox's UI.)
How are you able to interact with your OS? It must be some kind of black magic... or maybe it's because your OS scheduler knows how to prioritize threads properly so that you can multitask under load.
There is no magic involved here.
On Tue, May 13, 2014 at 1:57 PM, Ehsan Akhgari <[email protected] <mailto:[email protected]>> wrote: How does this support your argument exactly? It has nothing to do with my argument, it has to do with yours. You are suggesting that people should dynamically resize their threadpools. I'm bringing up the fact that web workers were /designed/ to not be used in this manner in the first place.
OK, so you're asserting that it's impossible to implement a resizing worker pool on top of Web Workers. I think you're wrong, but I'll grant you this assumption. ;-) Just wanted to make it clear that doing that won't bring us closer to a conclusion in this thread.
Cheers, Ehsan _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
