[whatwg] Limit on number of parallel Workers.

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 <http://figushki.com/test/workers/workers.html> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090609/0b77faba/attachment.htm>

Received on Tuesday, 9 June 2009 21:33:44 UTC