Weak references and destructors

Erik Corry erik.corry at gmail.com
Fri Dec 11 00:45:53 PST 2009


2009/12/11 Mark S. Miller <erights at google.com>:
>
>
> 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
> above:
>
> "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."

I really dislike this definition.  This would imply that anyone could
overwrite setTimeout and get a completely different behaviour.  If
overwriting is impossible then it introduces setTimeout into the
standard by the backdoor.

I'd prefer an underspecified [[QueueForProcessing]] operation with no
connection to the global object and a note to say that in a browser it
would be expected to use the same mechanism as a setTimeout with a
timeout of zero.

>
>
>>
>> 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 ;-).

There are lots of misunderstandings around GC, where people expect
this sort of callback to happen at some predictable time.  If there's
no memory pressure then there's no reason to expect the GC to ever be
run even if the program runs for ever.  It would be nice to have some
indication in the text of the standard that discouraged people from
expecting a callback at some predictable time.  For example if people
want to close file descriptors or collect other resources that are not
memory using this mechanism it would be nice to discourage them
(because it won't work on a machine with lots of memory and not so
many max open fds).

>> 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){}" ?
>
> --
>    Cheers,
>    --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list