On revoking access to the target of a proxy

Tom Van Cutsem tomvc.be at gmail.com
Thu Aug 23 07:19:04 PDT 2012

2012/8/22 David Bruant <bruant.d at gmail.com>

> Le 21/08/2012 17:41, Tom Van Cutsem a écrit :
>> 2) it reintroduces a subtle issue from the old design that had to do with
>> fixing a proxy while it still has pending trap activations on the runtime
>> stack: an unrevoked proxy may call one of its traps and be revoked by the
>> time the trap returns.
> As a complement to what you're saying, in this case, the proxy user
> revokes the proxy (intentionally or not) in the middle of a normal object
> operation (get/set/has/etc.). After this operation, the proxy is revoked.
> We can say "revoked internally" since it has not been does by an external
> proxy user, but a trap.

Not necessarily: the trap, while executing, may call on some external code
which then does the revocation, so there's no reason to call it "revoked
internally" (i.e. the revocation may happen arbitrarily deep in the call
stack, it may not occur lexically in the scope of the trap).

>  For invariant enforcement to work correctly, the trap's result must be
>> verified against the original target.
> Or should it just throw, considering that no invariant holds for
> internally revoked proxy?
> Returning a last result while the proxy has been internally revoked might
> be considered as a leak.
> [example snipped]
> I have no strong opinion as for what is best between doing a "last
> successful operation" or throwing for internally revoked proxies, I just
> wanted to share this option for the sake of completeness.

The way proxies are currently specced (see <
the [[Target]] of a proxy is always read into a local variable before
calling the trap, and in the post-trap assertion checks, this local
variable is then used. Thus, it doesn't matter whether the proxy was
revoked in the mean time or not.

I don't see the harm in still allowing pending trap activations to return
gracefully upon revocation.

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

More information about the es-discuss mailing list