<div>That's a great approach. Is the pool of OS threads per-domain, or per browser instance (i.e. can a domain DoS the workers of other domains by firing off several infinite-loop workers)? Seems like having a per-domain thread pool is an ideal solution to this problem.</div>
<div><br></div><div>-atw<br><br><div class="gmail_quote">On Tue, Jun 9, 2009 at 9:33 PM, Dmitry Titov <span dir="ltr"><<a href="mailto:dimich@chromium.org">dimich@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><div class="gmail_quote">On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><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><div>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?</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>


</blockquote></div><br></div></div><div>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.</div><div>
<br></div>
<div><a href="http://figushki.com/test/workers/workers.html" target="_blank">Here</a> 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 :-) </div>

<div><br></div><font color="#888888"><div>Dmitry</div>
</font></blockquote></div><br></div>