On May 16, 2009, at 11:25 AM, Mark S. Miller wrote:
On Fri, May 15, 2009 at 2:26 PM, Brendan Eich <bren...@mozilla.com>
wrote:
[...] but plain old iloop DOS prevention as practiced in browsers
does *not* reload the page. And the browser APIs are full of ways
to detect
that finallys didn't run, through effects overt and covert.
[...]
Just consider iloop DOS prevention as practiced in browsers today:
finally
may not run. That's enough.
Have you tried this lately? In a squarefree shell on several browser
I typed in
var x = 8; try { while (true) {} } finally { x = 7; }
Results:
Safari promped. I told it to "stop" scripts. Afterwards, the event was
terminated, but scripts on the page were still able to run. x was 7,
indicating that finallys were executed on the way out.
Seems like an exception (possibly uncatchable?) was thrown.
IE: Similar, but x was 8 indicating that no finallys were run.
FF, Opera, Chrome: That squarefree shell remained hung and I never got
prompted, even after leaving these to run overnight. I am surprised. I
have not heard of this behavior.
Not sure what's up there -- which version of Firefox? Also, you can
run that code in a javascript: URL typed directly into the address
bar, or into the Error Console's text input.
I just entered
javascript:var x = 8; try { while (true) {} } finally { x = 7; }; void 0
into the address bar in Firefox 3.5 pre-release, and after ten seconds
(we use wall time to watchdog scripts) I got the slow script dialog.
Clicking Stop then terminated the loop, and as with IE, the finally
ran, as
javascript:alert(x)
confirmed by alerting 8 not 7.
The IE and Firefox policy is meant to stop the script for good.
Running finallys might just re-iloop, leading to the slow script
dialog, user picks Stop, finallys run, ad infinitum:
javascript:var x = 8; (function f() { try { while (true) {} } finally
{ x = 7; f(); } })(); void 0
An implementation supporting tail call optimization wouldn't grow its
stack so the stack growth limiting done by quality implementations ;-)
would not save you.
This seems a good reason not to run finallys.
The same issue came up with our attempts to automate generator close
from the GC, as Python does. This is a no-no in browsers. In other
embeddings, it could be desirable, but it overconstrains the
implementation (CPython uses refcounting with cycle GC, and the prompt
finalization is expected by programmers).
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
