Weak references and destructors
Brendan Eich
brendan at mozilla.com
Thu Dec 10 22:48:47 PST 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091210/903bd077/attachment.html>
More information about the es-discuss
mailing list