On revoking access to the target of a proxy

Tom Van Cutsem tomvc.be at gmail.com
Tue Aug 21 08:41:11 PDT 2012

(sorry for the slow reply, catching up on e-mail)

So the old fix() trap is back with a vengeance, it seems!

To answer Mark's question of what other downsides there are to dropping the
1) it would require an additional check on every trapped operation to
verify whether the proxy is revoked or not, throwing an exception if it is.
Nothing critical since we're already on the slow path, but this
"revocation" check is new overhead.

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. For invariant enforcement to work correctly, the
trap's result must be verified against the original target. So, the proxy
must ensure that it holds on to the original target *before* calling the
trap, and use that stored pointer after the trap returns. Again, not a
strong argument against, but it's an important new implementation detail.

(by the way: because we functionally pass the target as first argument to
each trap invocation, revoking a proxy would not affect active trap
activations at all: they just keep on referring to the original target
parameter until they complete. This is Good.)

David's proposals are all very much consistent with the current Proxy
design. I would prefer option 3 (having a separate RevokableProxy
constructor that returns a {proxy, revoke} pair), since it somewhat
isolates the additional complexity in a dedicated abstraction. Also, while
I suspect that for spec economy, we would want to spec Proxy instances
simply as RevokableProxy instances that are never revoked, for implementors
it makes for an easy distinction, allowing them to elide the revocation
check for Proxy instances).

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

More information about the es-discuss mailing list