[whatwg] Limit on number of parallel Workers.

Michael Nordman michaeln at google.com
Tue Jun 9 19:07:00 PDT 2009

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090609/508f224d/attachment-0002.htm>

More information about the whatwg mailing list