On Wed, Jul 8, 2009 at 1:59 AM, Ian Hicksoni...@hixie.ch wrote:
I include below, for the record, a set of e-mails on the topic of settings
limits on Workers to avoid DOS attacks.
As with other such topics, the HTML5 spec allows more or less any
arbitrary behaviour in the face of hardware
This type of UA-specific setting is something best left outside the spec
entirely.
Yup
On Wed, Jul 8, 2009 at 10:08 AM, Drew Wilson atwil...@google.com wrote:
I think Ian's decision to add no language to the spec is the correct one.
To be clear, we were never asking for Ian to put a limit in
I include below, for the record, a set of e-mails on the topic of settings
limits on Workers to avoid DOS attacks.
As with other such topics, the HTML5 spec allows more or less any
arbitrary behaviour in the face of hardware limitations. There are a
variety of different implementations
http://figushki.com/test/workers/workers.html
I just wanted to point out that this example illustrates a bug in
Safari/Chromium's implementation of workers (I think?). The example
worker script ('fib.js') does this:
function onmessage(evt) { ... }
addEventListener(message, onmessage, true);
On Mon, Jun 22, 2009 at 3:38 PM, ben turnerbent.mozi...@gmail.com wrote:
http://figushki.com/test/workers/workers.html
I just wanted to point out that this example illustrates a bug in
Safari/Chromium's implementation of workers (I think?). The example
worker script ('fib.js') does this:
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
On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordmanmicha...@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
On Wed, Jun 10, 2009 at 1:46 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordmanmicha...@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
The current thinking would be a smaller limit per page (i.e. includes all
iframes and external scripts), say around 16 workers. Then a global limit
for all loaded pages, say around 64 or 128. The benefit of two limits is to
reduce the chance of pages behaving differently depending on what other
Hi WHATWG!
In Chromium, workers are going to have their separate processes, at least
for now. So we quickly found that while(true) foo = new Worker(...)
quickly consumes the OS resources :-) In fact, this will kill other browsers
too, and on some systems the unbounded number of threads will
I believe that this will be difficult to have such a limit as sites
may rely on GC to collect Workers that are no longer running (so
number of running threads is non-deterministic), and in the context of
mix source content (mash-ups) it will be difficult for any content
source to be sure
On Tue, Jun 9, 2009 at 6:13 PM, Dmitry Titovdim...@chromium.org wrote:
Hi WHATWG!
In Chromium, workers are going to have their separate processes, at least
for now. So we quickly found that while(true) foo = new Worker(...)
quickly consumes the OS resources :-) In fact, this will kill other
On Tue, Jun 9, 2009 at 6:28 PM, Oliver Hunt oli...@apple.com wrote:
I believe that this will be difficult to have such a limit as sites may
rely on GC to collect Workers that are no longer running (so number of
running threads is
non-deterministic), and in the context of mix source content
This is a bit of an aside, but section 4.5 of the Web Workers spec no longer
makes any guarantees regarding GC of workers. I would expect user agents to
make some kind of best effort to detect unreachability in the simplest
cases, but supporting MessagePorts and SharedWorkers makes authoritatively
It occurs to me that my statement was a bit stronger than I intended - the
spec *does* indeed make guarantees regarding GC of workers, but they are
fairly loose and typically tied to the parent Document becoming inactive.
-atw
On Tue, Jun 9, 2009 at 6:42 PM, Drew Wilson atwil...@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
On Tue, Jun 9, 2009 at 7:07 PM, Michael Nordman micha...@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
17 matches
Mail list logo
