- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 12 Jul 2013 17:03:26 +0000 (UTC)
- To: Kenneth Russell <kbr@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>
On Wed, 9 Jan 2013, Kenneth Russell wrote: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#creating-workers > doesn't seem to define what happens if there aren't enough resources to > create a separate parallel execution environment. User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. -- http://whatwg.org/html/#hardwareLimitations > Would it be legal for a UA to consider this as violating a policy > decision and throw SecurityError? Or is that step intended to reflect a > static decision, such as whether the UA allows workers to run at all? > > If this behavior isn't specified, could some graceful failure mode be > specified? Currently some UAs terminate the execution of the page > attempting to start the worker, which is obviously undesirable. We can't really define behaviour in hardware-constrained situations, because you might not have the resources to do what the spec requires. (In the most trivial case: the spec right now technically requires that when you don't have enough resources to start a new worker, that you start a new worker anyway. Obviously you can't do that.) Implementors are encouraged to not have limits, but when you hit the limits, you just need to do what seems best. My recommendation here would be to just queue the worker up and wait for there to be available resources. Or, even better, to run workers in a thread pool, and when you have more workers than threads, time share the threads between the workers. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 12 July 2013 17:03:52 UTC