[whatwg] Limit on number of parallel Workers.


In Chromium, workers are going to have their separate processes, at least
for now. So we quickly found that "while(true) foo = new Worker(...)"
quickly consumes the OS resources :-) In fact, this will kill other browsers
too, and on some systems the unbounded number of threads will effectively
"freeze" the system beyond the browser.

We think about how to reasonably place limits on the resources consumed by
'sea of workers'. Obviously, one could just limit a maxumum number of
parallel workers available to page or domain or browser. But what do you do
when a limit is reached? The Worker() constructor could return null or throw
exception. However, that seems to go against the spirit of the spec since it
usually does not deal with resource constraints. So it makes sense to look
for the most sensible implementation that tries best to behave.

Current idea is to let create as many Worker objects as requested, but not
necessarily start them right away. So the resources are not allocated except
the thin JS wrapper. As long as workers terminate and the number of them
decreases below the limit, more workers from the "ready queue" could be
started. This allows to support implementation limits w/o exposing them.

This is similar to how a 'sea of XHRs' would behave. The test page
here<http://www.figushki.com/test/xhr/xhr10000.html> creates
10,000 async XHR requests to distinct URLs and then waits for all of them to
complete. While it's obviosuly impossible to have 10K http connections in
parallel, all XHRs will be completed, given time.

Does it sound like a good way to avoid the resource crunch due to high
number of workers?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090609/11970404/attachment-0001.htm>

Received on Tuesday, 9 June 2009 18:13:49 UTC