For what it's worth, it's unlikely that we at mozilla will implement this anytime soon, if at all. We're currently working on trying to reduce the ability to fingerprint [1] and this would be a step in the wrong direction for us. This is based on discussions with security folks here, so it's possible that others at mozilla has different opinions, but I still think it's unlikely that this will get past our security reviews for now.
[1] http://panopticlick.eff.org/ / Jonas On Thu, Jun 10, 2010 at 3:42 AM, Mike Wilson <mike...@hotmail.com> wrote: > Hi Robert, > > I think using the term "execution context" here is not really > advisable, as a JS call stack will contain a new execution > context for every function call level. Thus, a property named > maxExecutionContexts might as well be interpreted as the > maximum call stack depth in a single worker. > > See chapter 10 and f ex 13.2.1 of: > http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf > > It might be better off to play on "hardware" terms like CPU, > Execution Unit, etc? > > Best regards > Mike Wilson > > Ennals, Robert wrote: >> 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: public-webapps-requ...@w3.org [mailto:public-webapps- >> > requ...@w3.org] On Behalf Of bugzi...@jessica.w3.org >> > Sent: Friday, May 28, 2010 4:09 PM >> > To: public-webapps@w3.org >> > 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: i...@hixie.ch >> > ReportedBy: robert.enn...@intel.com >> > QAContact: member-webapi-...@w3.org >> > CC: m...@w3.org, public-webapps@w3.org >> > >> > >> > 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. >> >> > > >
