On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson i...@hixie.ch wrote:
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
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
On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson i...@hixie.ch wrote:
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
the
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
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
