[whatwg] Limit on number of parallel Workers.

[Drew Wilson]

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-0002.htm>