[whatwg] Workers: what should happen when exceeding worker limit?

[Dmitry Titov]

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...

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):

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.

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.

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.

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
:-)

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.

Again, knowing your use case in more details can help in the future design
steps here.

Dmitry

On Thu, Sep 23, 2010 at 2:06 AM, Ivan Kozik <ivan at ludios.org> wrote:

> What should happen when instantiating a Worker that cannot be started
> because of the limit on the number of workers?  Chrome 6 and Chromium
> 7.0.532.0 (60255) put the 17th worker in a queue, to be created when
> some existing worker terminates.  This queue seems to be limitless in
> size (or at least it is large).  In Opera 10.70 (9049), instantiating
> the 17th Worker throws "Error: QUOTA_EXCEEDED_ERR".
>
> I'd much prefer that it failed immediately, rather than being put in a
> queue.  I use a SharedWorker as an enhancement, and I don't want to
> implement a timeout for the Worker spawning (I'd rather have it fail,
> so that I can immediately do something else).  I can avoid spawning
> more than 16 workers, but I never know if another tab has already
> created enough workers to exhaust the global worker limit (64 in
> Chrome, ~118 in Opera).  And if I really want to spawn the worker, I
> can always try spawning it again soon.
>
> This message describes why Chromium queues up excessive workers:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html
>
> I'm not sure that making it work like a "sea of XHRs" is the right
> thing, for two reasons:
> 1) Workers often stay running for a long time; XHRs are usually
> short-lived.
> 2) Most web applications don't expect to definitely have access to a
> Worker, so they work around it by running code in the page instead of
> the worker.  This same code path could be used when the worker limit
> is exhausted.  With XHRs, there's generally no workaround: you need
> the data, no matter what.
>
> Here's a crude test page that instantiates 17 workers:
> <!doctype html>
> <div id="log"></div>
> <script>
> var workers = [];
> for(var i=0; i < 17; i++) {
>  try {
>    workers.push(new Worker('empty.js'));
>    document.getElementById('log').innerHTML +=
>        'Worker #' + i + ' instantiated.<br>';
>  } catch(e) {
>    document.getElementById('log').innerHTML += e.toString() + '<br>';
>  }
> }
> </script>
>
> Any thoughts would be appreciated.
>
> Thanks,
>
> Ivan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100923/5422aed0/attachment-0002.htm>