This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9823 - Add "maxExecutionContexts" property with number of hardware execution contexts
Summary: Add "maxExecutionContexts" property with number of hardware execution contexts
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Web Workers (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2010-05-28 23:09 UTC by Rob Ennals
Modified: 2010-08-27 18:47 UTC (History)
4 users (show)

See Also:


Description Rob Ennals 2010-05-28 23:09:02 UTC
It is likely that people will want to use the Web Workers API for creating multiple threads to perform some kind of CPU-bound computation more efficiently than they could with a single thread. In particular, Section 1.2.6 (Delegation) talks about splitting a task across multiple workers in order to gain performance.  In this particular example, the number of workers is fixed at 10, but this is likely to be the wrong number in most cases. 

Right now, the spec gives no guidance to developers about how many workers they should use for compute-bound jobs. In the absence of such information, it seems likely that developers will do something ugly like choose a fixed number that seemed to work well on the device they tested on, attempt to identify which of a finite number of known devices the app is running on using user-agent sniffing, or just create far more workers than needed in the hope that the user agent will deal with the problem. 

I suggest we just add a simple maxExecutionContexts property with descriptive text like:
 This value is the maximum number of hardware execution contexts that may be available to applications running in the User Agent.  Other activity in the User Agent or on the system may be using these resources at any time (including during or after the request for information is made).  It is not the number of free, unused resources. User Agents may exclude dedicated processors that they know are not available for applications or may choose to set thread priorities low for applications that overuse system resources by starting too many WebWorkers on a busy system.

maxExecutionContexts is not an optimal or recommended number of workers to create. If another app is using some of the cores, then the optimal number of cores may be lower. If your workers are often IO bound, then the optimal number of cores may be higher. Similarly if worker-communication costs are significant, it may not be useful to use all available cores.

maxExecutionContexts is however a number that can be useful for an app that wants to choose an appropriate number of workers to create. At the simplest level, the fact that maxExecutionContexts is greater than 1 tells an app that it may be able to gain some performance from some level of parallelism, and the fact that maxExecutionContexts is a large number may indicate that it is wise for the app to split its work into finer-grain chunks than if it was smaller.

It is up to an individual developer to determine how the number of workers they create corresponds to "maxExecutionContexts"; however it is likely that the availability of this number will help them make better decisions than they would  if this information was not available.

Comment 1 Rob Ennals 2010-06-08 17:20:54 UTC
The natural place to put this attribute seems to be on the navigator object. This property should be made available on both the main page and within a web worker.

For example, one way this property could be defined would be with the following WebIDL:

[Supplemental, NoInterfaceObject]
interface NavigatorWorkerInfo {
   readonly attribute int maxExecutionContexts;

Navigator implemets NavigatorWorkerInfo;
WorkerNavigator implements NavigatorWorkerInfo;
Comment 2 Ian 'Hixie' Hickson 2010-08-27 18:26:46 UTC
I think this is something that deserves closer investigation, based on implementation experience.
Comment 3 Jonas Sicking (Not reading bugmail) 2010-08-27 18:47:00 UTC
For posterity: There is a serious risk of fingerprinting here. See for some information on the subject.

It's certainly possible to use workers to approximate the number of cores even if we don't add a maxExecutionContexts. However it will make it significantly harder to do so, and it likely will requiring heavily loading all cores on the CPU for a while while measuring. This will likely significantly reduce the number of sites that are going to use this techniques. For example an advertizing network that does so is unlikely to be popular among websites.

Because of this, I don't see mozilla implementing something like this at this time.