On Fri, May 15, 2009 at 2:26 PM, Brendan Eich <[email protected]> wrote: >> I am assuming that a hard stop destroying an event loop also destroys >> (at least makes inaccessible) all objects that were able to execute >> within that event loop. > > You're right that this is necessary with threads and fail-stop information > flow systems, 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.
JavaScript is used in many hosting environments besides browsers. In particular, there is rapidly rising enthusiasm for server-side use of JavaScript, where integrity may matter more, and the equivalent of reloading may be perfectly fine after a preemptive termination. The language spec should avoid making such higher integrity uses harder. I'm curious: What ways do you have in mind to detect that finallys didn't run? >> So, the anthropic side channel enables B to communicate what Brendan >> might call a half a bit of information to C. > > You must be referring to my slides at > http://www.dagstuhl.de/Materials/index.en.phtml?09141 -- I should have > better slides blogged next week. I was indeed. I look forward to your new slides. -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
