[whatwg] Workers: what should happen when exceeding worker limit?
ian at hixie.ch
Thu Dec 30 16:11:48 PST 2010
On Thu, 23 Sep 2010, Ivan Kozik wrote:
> What should happen when instantiating a Worker that cannot be started
> because of the limit on the number of workers?
That's a hardware limitation, and as such is something we tend to leave up
to the user agents. In practice, it's often the case that user agents are
very constrained in how they can deal with hardware limitations (e.g. if
the user agent cannot allocate more memory, then it might not be able to
allocate memory to fire an exception, or to keep track of the worker to
run it later), and therefore we tend to leave that open. So long as the
limitations are big enough that most pages don't run into them, it doesn't
really matter -- a user agent with a compatibility issue can almost
always just increase the limits if pages would otherwise break!
> 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 guess the simplest answer is "don't use more than 16 workers". There's
really not much point in doing so anyway, since most systems don't have 16
cores today. (This will naturally change in the future, but then so will
> I'd much prefer that it failed immediately, rather than being put in a
Unfortunately we can't really require immediate failure, since there'd be
no way to test it or to prove that it wasn't implemented -- a user agent
could always just say "oh, it's just that we take a long time to launch
the worker sometimes". (Performance can be another hardware limitation.)
> 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.
If you have performance constraints, then you should just use timeouts to
test whether the worker started -- that way you'll do the worker-less
fallback behaviour regardless of whether the timeout fired because workers
are just slow on the user's computer or because there are no more worker
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg