<div>Thanks for the feedback! I'd love to know more about your use case (if possible), since it may motivate further thinking on these limits...</div><div><br></div><div>Indeed, the option of immediately throwing was also considered. It didn't look obviously better for the following reasons (I may forget something, but that's what I remember):</div>
<div><br></div><div>1. Workers are asynchronous so even a successful (not-queued) start will incur some unspecified delay - the Worker object will be created instantly but actual initial script or postMessage handlers won't be invoked for some time. This time varies (can be seconds on a netbook with many opened tabs) so the page can not build expectations on "instant start" anyways. This reduces the benefit of "knowing right away that worker can not start".  In your case, for example, you might want a timer anyways, to close the worker and use the alternative route that you seem to have.</div>
<div><br></div><div>2. There are use cases which would use workers to perform certain operation and then close the workers. Typical example would be some operation that is longer then "instant" so the page UI would like to be responsive with Cancel button ready. Once the operation completes, the workers are left to terminate and die. This can take a moment and the page does not know when previous workers actually terminate. If the page can not create new workers during this finalization time, it creates more complexity for it. Having a queue solves those edge conditions nicely.</div>
<div><br></div><div>3. The current Chrome limits of 16 per page and 64 total are much lower then we would like them to be, due to implementation limits we hope to remove in the future. These limits should be high enough to realistically never prompt app developers to consider coding around them. Basically creating multiple workers should only have a limit related to memory. It might happen that current queues will happen to be an implementation detail of Chrome for some time and does not need to be reflected in the spec.</div>
<div><br></div><div>4. If we are to create a mechanism that provides useful guarantees around timely execution in multi-thread environment, I believe we'd have to specify much more complex api, providing fair scheduling, guarantee against starvation, some real-time support etc - but we are not there yet :-) </div>
<div><br></div><div>5. Normally, the JS APIs that can return "quota exceeded" errors typically imply mechanisms for granting/monitoring/revoking the said quotas, perhaps with UI for the user, as Database API does for example. No matter how initial quotas are set, there will be the app that legitimately needs a lot of resources while we also don't want to give the same to any random page. I think we don't have enough evidence yet to consider worker creation in the same category, but if it comes to that at some point, the exception from Workers constructor probably won't be enough.</div>
<div><br></div><div>Again, knowing your use case in more details can help in the future design steps here.</div><div><br></div><div>Dmitry<br><br><div class="gmail_quote">On Thu, Sep 23, 2010 at 2:06 AM, Ivan Kozik <span dir="ltr"><<a href="mailto:ivan@ludios.org">ivan@ludios.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">What should happen when instantiating a Worker that cannot be started<br>
because of the limit on the number of workers?  Chrome 6 and Chromium<br>
7.0.532.0 (60255) put the 17th worker in a queue, to be created when<br>
some existing worker terminates.  This queue seems to be limitless in<br>
size (or at least it is large).  In Opera 10.70 (9049), instantiating<br>
the 17th Worker throws "Error: QUOTA_EXCEEDED_ERR".<br>
<br>
I'd much prefer that it failed immediately, rather than being put in a<br>
queue.  I use a SharedWorker as an enhancement, and I don't want to<br>
implement a timeout for the Worker spawning (I'd rather have it fail,<br>
so that I can immediately do something else).  I can avoid spawning<br>
more than 16 workers, but I never know if another tab has already<br>
created enough workers to exhaust the global worker limit (64 in<br>
Chrome, ~118 in Opera).  And if I really want to spawn the worker, I<br>
can always try spawning it again soon.<br>
<br>
This message describes why Chromium queues up excessive workers:<br>
<a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html" target="_blank">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html</a><br>
<br>
I'm not sure that making it work like a "sea of XHRs" is the right<br>
thing, for two reasons:<br>
1) Workers often stay running for a long time; XHRs are usually short-lived.<br>
2) Most web applications don't expect to definitely have access to a<br>
Worker, so they work around it by running code in the page instead of<br>
the worker.  This same code path could be used when the worker limit<br>
is exhausted.  With XHRs, there's generally no workaround: you need<br>
the data, no matter what.<br>
<br>
Here's a crude test page that instantiates 17 workers:<br>
<!doctype html><br>
<div id="log"></div><br>
<script><br>
var workers = [];<br>
for(var i=0; i < 17; i++) {<br>
  try {<br>
    workers.push(new Worker('empty.js'));<br>
    document.getElementById('log').innerHTML +=<br>
        'Worker #' + i + ' instantiated.<br>';<br>
  } catch(e) {<br>
    document.getElementById('log').innerHTML += e.toString() + '<br>';<br>
  }<br>
}<br>
</script><br>
<br>
Any thoughts would be appreciated.<br>
<br>
Thanks,<br>
<font color="#888888"><br>
Ivan<br>
</font></blockquote></div><br></div>