On May 16, 2009, at 11:25 AM, Mark S. Miller wrote:
> On Fri, May 15, 2009 at 2:26 PM, Brendan Eich <brendan at 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