[Webkit-unassigned] [Bug 132588] support for navigator.cores or navigator.hardwareConcurrency

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=132588





--- Comment #7 from Rik Cabanier <cabanier at adobe.com>  2014-05-05 21:33:12 PST ---
(In reply to comment #4)
> My turn to chime in.
> 
> - Reiterating the fingerprinting problem that's already been mentioned that we have no response to.

People on the blink team don't share this concern. I also don't see how valuable this information is, especially since it's easy to infer

> - "Number of physical cores" does not correlate to the number of simultaneous tasks supporter
> - "Number of physical cores" does not correlate to computing resources currently available.

Does WebKit limit the number of Web Worker threads like gecko does, or does it launch as many as the author requests?
If it limits the amount, that should be the number that this API returns.
If not, this API should return the number of logical CPU instances.

> There modern approach to "let me do as much work as possible without hindering overall performance on the system" that at least some systems support.  Grand Central Dispatch on OS X, for example, will executed more tasks simultaneously when the resources are available but scale back when other apps demand some resources.
> Is there a real problem that having this bit available would solve that couldn't also be solved by a GCD-style mechanism?

Even with a GCD-like solution, an author would often want to know how many threads can run at the same time so a task is not broken up in too many pieces or too many tasks are launched.
A GCD-like solution is much more difficult to engineer and to agree upon (and IMO for most cases overkill.) Desktop apps have been doing fine with just knowing the number of CPUs; what makes the web platform different?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.