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 implements NavigatorWorkerInfo;
WorkerNavigator implements NavigatorWorkerInfo;
-Rob
> -----Original Message-----
> From: [email protected] [mailto:public-webapps-
> [email protected]] On Behalf Of [email protected]
> Sent: Friday, May 28, 2010 4:09 PM
> To: [email protected]
> Subject: [Bug 9823] New: Add "maxExecutionContexts" property with
> number of hardware execution contexts
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9823
>
> Summary: Add "maxExecutionContexts" property with number of
> hardware execution contexts
> Product: WebAppsWG
> Version: unspecified
> Platform: PC
> OS/Version: Windows XP
> Status: NEW
> Severity: normal
> Priority: P2
> Component: Web Workers (editor: Ian Hickson)
> AssignedTo: [email protected]
> ReportedBy: [email protected]
> QAContact: [email protected]
> CC: [email protected], [email protected]
>
>
> 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.
>
>
> -Rob
>
> --
> Configure bugmail:
> http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
