- From: Drew Wilson <atwilson@google.com>
- Date: Wed, 10 Jun 2009 10:24:35 -0700
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. -atw On Tue, Jun 9, 2009 at 9:33 PM, Dmitry Titov <dimich at chromium.org> wrote: > 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/20090610/b6e5d016/attachment-0001.htm>
Received on Wednesday, 10 June 2009 10:24:35 UTC