On Tue, 19 May 2009, João Eiras wrote: > > > > How is this different from making two mutations per mutation event, or > > calling postMessage() twice for each invokation of the 'message' > > event, or loading two new iframes every time an iframe's 'load' event > > fires? > > It's quite different because in those cases, the events or actions are > all limited to one single runtime, which means all these actions are > queued. A sane user agent can share a part of its cpu time between all > the active runtimes, and keeping the other documents usable while one > fork bombs itself with events, being the leftover problem the amount of > memory needed. > > With storage events, the user agent must send events to unrelated > runtimes, which can escalate immensely, therefore filling all the other > runtimes' event queues with the superfluous events. If the user agent > has no protection against this, then the user will be forced to close > the whole browser, and not just the webpage that is misbehaving. Even if we posit a system where there are unrelated runtimes that can communicate in this way, within each runtime the user agent can apply the same protections. Furthermore, since runtimes can now communicate anyway (e.g. using shared workers), I really don't see which this is an unusual problem. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 10 June 2009 05:07:16 UTC