<div class="gmail_quote">On Wed, Jun 10, 2009 at 1:46 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordman<<a href="mailto:michaeln@google.com">michaeln@google.com</a>> wrote:<br>
>><br>
</div><div><div></div><div class="h5">>> 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>
>><br>
>> / Jonas<br>
><br>
> Thats a really good model. Scalable and degrades nicely. The only problem is<br>
> with very long running operations where a worker script doesn't return in a<br>
> timely fashion. If enough of them do that, all others starve. What does FF<br>
> do about that, or in practice do you anticipate that not being an issue?<br>
> Webkit dedicates an OS thread per worker. Chrome goes even further (for now<br>
> at least) with a process per worker. The 1:1 mapping is probably overkill as<br>
> most workers will probably spend most of their life asleep just waiting for<br>
> a message.<br>
<br>
</div></div>We do see it as a problem, but not big enough of a problem that we<br>
needed to solve it in the initial version.<br>
<br>
It's not really a problem for most types of calculations, as long as<br>
the number of threads is larger than the number of cores we'll still<br>
finish all tasks as quickly as the CPU is able to. Even for long<br>
running operations, if it's operations that the user wants anyway, it<br>
doesn't really matter if the jobs are running all in parallel, or<br>
staggered after each other. As long as you're keeping all CPU cores<br>
busy.<br>
<br>
There are some scenarios which it doesn't work so well for. For<br>
example a worker that works more or less infinitely and produces more<br>
and more accurate results the longer it runs. Or something like a<br>
folding@home website which performs calculations as long as the user<br>
is on a website and submits them to the server.<br>
<br>
If enough of those workers are scheduled it will block everything else.<br>
<br>
This is all solveable of course, there's a lot of tweaking we can do.<br>
But we figured we wanted to get some data on how people use workers<br>
before spending too much time developing a perfect scheduling<br>
solution.</blockquote><div><br></div><div>I never did like the Gears model (1:1 mapping with a thread). We were stuck</div><div>with a strong thread affinity due to other constraints (script engines, COM/XPCOM).</div><div>
But we could have allowed multiple workers to reside in a single thread.</div><div>A thread pool (perhaps per origin) sort of arrangement, where once a worker</div><div>was put on a particular thread it stayed there until end-of-life.</div>
<div><br></div><div>Your FF model has more flexibility. Give a worker a slice</div><div>(well where slice == run-to-completion) on any thread in the</div><div>pool, no thread affinity whatsoever (if i understand correctly).</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br>