Weak references and destructors

Mark S. Miller erights at google.com
Thu Dec 10 22:17:58 PST 2009

On Thu, Dec 10, 2009 at 11:38 AM, Brendan Eich <brendan at mozilla.com> wrote:

> On Dec 10, 2009, at 11:27 AM, Mark S. Miller wrote:
> By all means, let's continue hashing it out. I posted this proposal to
> es-discuss and presented it to the committee some time ago. I do not recall
> any serious objections, and I do recall several positive responses. However,
> the committee has not yet made any decision. If there were serious
> objections I have forgotten, my apologies, and I ask that you (re?)post them
> to es-discuss.
> Allen had some thoughts, but we were out of time at the last face to face.
> I'll let him speak for himself.
> The issue that I raised at the last meeting, other than naming nits (which
> we can defer for now), was in response to this:
>  "All visible notification happens via setTimeout() in order to avoid plan
> interference hazards. Side effects from these notifications happen in their
> own event-loop turn, rather than being interleaved with any ongoing
> sequential computation. However, this requires us to promote setTimeout()and event-loop concurrency into the ES-Harmony specification, which is still
> controversial."
> from http://wiki.ecmascript.org/doku.php?id=strawman:weak_references.
> We may not standardize the execution model to the degree you hope.
> I do think we should standardize (set|clear)(Timeout|Interval) and
event-loop concurrency, as server-side JavaScript use is already moving
towards adopting it, making its need independent of the browser. However, I
agree that these proposals should be decoupled if possible. Accordingly, I
have kludged the weak pointer proposal by modifying the definitional WeakPtr
code at the top and adding the following text to the paragraph you quote

"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."

> We also may not agree on notification being guaranteed. At the last f2f I
> mentioned how generators in JS1.7+ have a close method, again after Python,
> but without the unnecessary GeneratorExit built-in exception object thrown
> by close at a generator in case it has yielded in a try with a finally.
> Naively supporting notification guarantees creates trivial denial of service
> attacks and accidents.
> Of course, we could say the universe ends without pending notifications
> being delivered, but in the effecttful browser, the multiverse goes on and
> there are lots of channels between 'verses ;-).
> 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){}" ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091210/b3245c55/attachment-0001.html>

More information about the es-discuss mailing list