<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5"><br>
</div></div>This is the solution that Firefox 3.5 uses. We use a pool of<br>
relatively few OS threads (5 or so iirc). This pool is then scheduled<br>
to run worker tasks as they are scheduled. So for example if you<br>
create 1000 worker objects, those 5 threads will take turns to execute<br>
the initial scripts one at a time. If you then send a message using<br>
postMessage to 500 of those workers, and the other 500 calls<br>
setTimeout in their initial script, the same threads will take turns<br>
to run those 1000 tasks (500 message events, and 500 timer callbacks).<br>
<br>
This is somewhat simplified, and things are a little more complicated<br>
due to how we handle synchronous network loads (during which we freeze<br>
and OS thread and remove it from the pool), but the above is the basic<br>
idea.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><div><br></div><div>Thats a really good model. Scalable and degrades nicely. The only problem is with very long running operations where a worker script doesn&#39;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?</div>
<div><br></div><div>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.</div>