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

[Glenn Maynard]

On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson <ian at 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 limits.)

This logic is only valid if threads are exclusively used for pushing
CPU-bound work to other cores.  They're not; it's perfectly normal to
create more threads than CPU cores, both for disk I/O-bounds threads
and network-bound threads.

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

Preferably, if a Worker is successfully created, the worker thread
starting must not block on user code taking certain actions, like
closing other threads.  That doesn't mean it needs to start
immediately, but if I start a thread and then do nothing, it's very
bad for the thread to sit in limbo forever because the browser expects
me to take some action, without anything to tell me so.

Timeouts are an ugly, brittle workaround.  They'd have to be
implemented for every created thread--even if you aren't creating many
threads, another component on the page may be.  Timeouts would need to
be high enough to not cause false positives even during swapping,
which means a delay long enough to be visible to the user.  I'd also
expect unpredictable behavior on mobile browsers; if the whole browser
is suspended after creating a thread, timeouts may expire even though
the thread was starting normally.

We need sensible, predictable error detection, not silent queuing.  I
can't think of any case where workers being queued is preferable to
failing outright.  If queuing is really necessary, please at least
give us a way to query whether a worker is queued.  That's far from
ideal--it would be hard to test user code properly--but at least we
could wrap worker creation to throw an exception if our worker threads
are being queued.

-- 
Glenn Maynard