[whatwg] Limit on number of parallel Workers.

[ben turner]

> http://figushki.com/test/workers/workers.html

I just wanted to point out that this example illustrates a bug in
Safari/Chromium's implementation of workers (I think?). The example
worker script ('fib.js') does this:

  function onmessage(evt) { ... }
  addEventListener("message", onmessage, true);

In Firefox this has the effect of registering the message listener
*twice* since 'onmessage' is an attribute on the worker global scope
object and is handled independently of
addEventListener/removeEventListener functions. This behavior matches
that of normal web pages, as well. Given this snippet, for example,
Firefox will alert twice on page load:

  function onload() { alert("load!"); }
  addEventListener("load", onload, false);

Webkit seems to behave strangely here... The above code only alerts
once, yet the following code alerts twice:

  onload = function(evt) { alert("load!"); }
  addEventListener("load", onload, false);

Does that make sense? Firefox treats both cases the same and alerts
twice always.

Anyway, regardless of what happens here, the worker example linked
above will run the fibonacci calculation twice per worker in Firefox.

-Ben

On Tue, Jun 9, 2009 at 9:33 PM, Dmitry Titov<dimich at chromium.org> wrote:
> On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordman <michaeln at google.com> wrote:
>>>
>>> This is the solution that Firefox 3.5 uses. We use a pool of
>>> relatively few OS threads (5 or so iirc). This pool is then scheduled
>>> to run worker tasks as they are scheduled. So for example if you
>>> create 1000 worker objects, those 5 threads will take turns to execute
>>> the initial scripts one at a time. If you then send a message using
>>> postMessage to 500 of those workers, and the other 500 calls
>>> setTimeout in their initial script, the same threads will take turns
>>> to run those 1000 tasks (500 message events, and 500 timer callbacks).
>>>
>>> This is somewhat simplified, and things are a little more complicated
>>> due to how we handle synchronous network loads (during which we freeze
>>> and OS thread and remove it from the pool), but the above is the basic
>>> idea.
>>>
>>> / Jonas
>>
>> Thats a really good model. Scalable and degrades nicely. The only problem
>> is with very long running operations where a worker script doesn't return in
>> a timely fashion. If enough of them do that, all others starve. What does FF
>> do about that, or in practice do you anticipate that not being an issue?
>> Webkit dedicates an OS thread per worker. Chrome goes even further (for
>> now at least) with a process per worker. The 1:1 mapping is probably
>> overkill as most workers will probably spend most of their life asleep just
>> waiting for a message.
>
> Indeed, it seems FF has a pretty good solution for this (at least for
> non-multiprocess case). 1:1 is not scaling well in case of threads and
> especially in case of processes.
> Here is a page that can create variable number of workers to observe the
> effects, curious can run it in FF3.5, in Safari 4, or in Chromium with
> '--enable-web-workers' flag. Don't click 'add 1000' button in Safari 4 or
> Chromium if you are not prepared to kill the unresponsive browser while the
> whole system gets half-frozen. FF continue to work just fine, well done guys
> :-)
> Dmitry