On Dec 10, 2009, at 10:17 PM, Mark S. Miller wrote:
"In order to postpone the issue, the spec implied by the above code should be taken literally: If there is no global binding for setTimeout or if it bound to a non-callable value (as the time WeakPtr is called), then no notifications happen. If the value of the global setTimeout is callable, then the GC calls it at some arbitrary time, passing in a frozen function whose only purpose is to call the registered executor function. If setTimeout has its normal binding (e.g., in the browser), then the executor will only be called later in a separate turn as expected, protecting us from plan interference hazards. A secure runtime in such an environment can always freeze the global setTimeout property, preventing its redefinition to something that could cause plan interference."
"When in doubt, use brute force." - K. Thompson
In general I'd like to decouple weak references from hairy execution model issues. If we can't do this, then the risk we'll fail to get weak refs into the next edition go up quite a bit. The obvious way to decouple is to underspecify.I think I'd be willing to weaken this from "eventual notification" to "optional eventual notification." But I do not yet understand this issue. How does a guarantee of eventual notification lead to any more vulnerability to denial of service than "while(true){}" ?
There is no guarantee of eventual notification, any more than there's a guarantee that an armed timeout will fire (navigation away cancels), or that an iloop can take forever. If there's no guarantee, then the spec should not say there is.
/be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
