<div class="gmail_quote">On Wed, Sep 16, 2009 at 2:21 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div>I think that setting an upper bound on the amount of time that can be spent in all unload handlers is a better solution than hacking the behavior of the Date API. Because (a) It&#39;s less likely to have unexpected side effects; and (b) there&#39;s no way for content authors to work around it, so we are less likely to end up in an &quot;arms race&quot; situation. There were worries expressed that swapping or context switching might trigger false positives, but I expect this is unlikely in practice, based on our experience with the slow script dialog.</div>
</div></blockquote><div><br></div><div>These were also my arguments.  And I think all of us agree that in principle setting a generic execution limit would be better.  In practice, we have strong reason to believe that false positives will be common with wall clock implementations, at least for Chromium (because of our multiprocess design, renderer swapping is actually a huge issue for us currently, which we&#39;re trying to address), and that it&#39;s still easy for authors to work around this even at low values like 100 ms (instead of 8 200 ms handlers, just kick off 32 50 ms handlers.  Repeat ad infinitum).</div>
<div><br></div><div>The goal of this change is to approximate an execution limit in a way that does not suffer from false positives and is also reasonable for a JS engine to implement, and to do it temporarily while providing &lt;a ping&gt; until the point when measurements show that authors have in general switched to use that.</div>
<div><br></div><div>As I tried to say on the bug, even the worst possible outcome, an &quot;arms race&quot;, doesn&#39;t actually result in net harm, and if it happens, we can decide whether to try and shift the approach to be more like this, or to give up and rip out the hack entirely.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>From reading the comments in the bug, it does not look like we have consensus on the right approach, even among Chrome developers.</div>
</div></blockquote><div><br></div><div>This is correct, but somewhat misleading.  Adam is to my knowledge the one Chromium developer, who only recently encountered this idea, who currently disagrees, compared to a large number of us who agree.</div>
<div><br></div><div>PK</div></div>