Holy mixed metaphors, Batman!
Boris Zbarsky wrote:
Whether WindowProxy corresponds to Vat or not is an interesting question, but I would guess in practice it does not.
Can you say more? We may end up with multiple distinct well-defined concepts, but let's shave closer with Occam's razor, if possible.
Wait, I don't even understand what analogy y'all have in mind. A Window is per Realm. A WindowProxy is per what? certainly not per Vat, as there are many WindowProxies co-residing in the same Vat. I don't see even any metaphorical similarity between a WindowProxy and a Vat. A Vat is not proxy-ish for any other similar concept.
Mark S. Miller wrote:
Wait, I don't even understand what analogy y'all have in mind. A Window is per Realm. A WindowProxy is per what? certainly not per Vat, as there are many WindowProxies co-residing in the same Vat. I don't see even any metaphorical similarity between a WindowProxy and a Vat. A Vat is not proxy-ish for any other similar concept.
I was just throwing out analogies to get this thread started :-P.
Is the problem just clash of metaphors (Vat vs. FooProxy vs. Realm)? I'm still not sure, but even if only that, seems worth addressing. "Isle" doesn't quite do it instead of "Vat", though ;-).
I sympathize on mixing of metaphors. If we can come up with some metaphors with more reach, so that more terms can be explained by reference to fewer metaphors, that would be great.
As with the Window and WindowProxy you mention, the reach of candidate metaphors should be judged also by how many existing names it can explain.
On 10/16/14, 5:58 PM, Brendan Eich wrote:
Can you say more?
Vats as currently specified have independent event loops and allow parallel JS execution, in the sense that they are totally disconnected from each other and have separate run-to-completion guarantees.
A window and its same-origin subframe have two separate WindowProxys but can't really be separate Vats given the above, yes?
Boris Zbarsky wrote:
On 10/16/14, 5:58 PM, Brendan Eich wrote:
Can you say more?
Vats as currently specified have independent event loops and allow parallel JS execution, in the sense that they are totally disconnected from each other and have separate run-to-completion guarantees.
A window and its same-origin subframe have two separate WindowProxys but can't really be separate Vats given the above, yes?
Yup, but doesn't help inspire fewer/pithier metaphors, alas. "Vat" from Mark's E work is meaningful to those who know that work, and that's valuable. But can we do better?
Again this sub-thread, is mostly about finding the right terms of art. If we can unify across specs (if not within), that's gravy.
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Brendan Eich
On Fri, Oct 17, 2014 at 6:23 AM, Brendan Eich <brendan at mozilla.org> wrote:
Again this sub-thread, is mostly about finding the right terms of art. If we can unify across specs (if not within), that's gravy.
Vat helps explaining workers, but not the rest.
FWIW, "constellation" is a term that some of us have been using for a while (at least in Mozilla) for a concept that seems to match "Vat". For example, in the context of:
- when we could have separate task queues on separate threads (as an unobservable impl detail to improve responsiveness): markmail.org/message/rgtaeeg4dssvwcdw
- which windows' script execution should be blocked by slow-script dialog: bugzilla.mozilla.org/show_bug.cgi?id=637264
Roughly speaking, a constellation is a set of transitively-reachable windows (and, as a special case, workers are their own constellations). Since reachability implies synchronous observable effects, this means all the code in all realms in the constellation must use the same event loop.
Cheers, Luke
P.S. A fun corner case to consider is whether cross-origin edges count as "reachable" in the definition of constellation. I think this boils down to whether origin A can (directly or indirectly) trigger (predictable, cross-browser, perhaps even standardized) synchronous execution in origin B via cross-origin-accessible Window or Location properties. I was just asking bz about this
On Oct 16, 2014, at 5:31 PM, Boris Zbarsky wrote:
On 10/16/14, 5:58 PM, Brendan Eich wrote:
Can you say more?
Vats as currently specified have independent event loops and allow parallel JS execution, in the sense that they are totally disconnected from each other and have separate run-to-completion guarantees.
A window and its same-origin subframe have two separate WindowProxys but can't really be separate Vats given the above, yes?
We've also talked about this in the other recent related thread.
As Vats are current specified (the ES6 spec essentially describes a single Vat), the host is responsible for making Job scheduling decisions for each Vat. This means that a host that is managing multiple Vats could impose a synchronous scheduling policy that spans multiple Vats. This seems like it may be sufficient to describe browsers behavior.
Till now I was neutral on the term "Vat". But part of the notion of Vat is that Vats are (mostly[1]) only asynchronously coupled. Two fully membraned subgraphs, interacting synchronously only through Proxies, would by my normal definitions be together in one Vat.
For this separation, where non-subvertable membrane boundaries impose security boundaries between disjoint subgraphs of the object graph, I use the term "Compartment". This corresponds well enough to the established meaning of "Compartment" in computer security.
[1] In E the issue of asynchronous-only coupling is broken into two concepts, the Vat and the Runner. Each Vat is within one Runner, and there can be multiple Vats within a Runner. Each Job (nee Turn) is associated with a one Vat. Each Runner is associated with a single threat of control. Each Job of any Vat within a Runner, once started, runs to completion before that Runner can start any of the other Jobs of any of its Vats. Thus, a single non-terminating Job of any Vat within a Runner prevents any further progress by any other Vat within that Runner. This is the only sense in which Vats within a Runner are synchronously coupled.
Objects within one Vat cannot synchronously invoke/access any objects/state within any other Vat, whether in the same Runner or not. So, I would say that Runners are units of concurrency, Vats are units of asynchrony, and Compartments are units of unmediated direct access.
Where is the spec for this? I know I'm a little late to the game.
On Thu, Oct 16, 2014 at 11:12 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Brendan Eich
Again this sub-thread, is mostly about finding the right terms of art.
From that perspective, I'd do s/vat/continent/, to match Allen's explanation that while only "political barriers" prevent transition of objects between realms, there's an actual barrier between vats/continents that requires some sort of artificial conveyance (i.e. structured clone, now known as "the boat algorithm" ;).
I like the physical separation analogies, fwiw. Hits my intuition a little better.
On 10/15/14, 4:38 PM, Mark S. Miller wrote:
Well, the WindowProxy to Window relationship is one-to-many. And Window pretty clearly corresponds to Realm (in the sense that there is a unique Realm associated with each Window).
Whether WindowProxy corresponds to Vat or not is an interesting question, but I would guess in practice it does not.