Weak references and destructors

[Brendan Eich]

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>