On 10/15/14, 3:45 PM, Allen Wirfs-Brock wrote:
Right, but in practice, for different-origin pages, don't you use various
forms of serialization/proxying to provide Vat-like object reference isolation?
Maybe.
First, note that being "different-origin" is not a static property due
to document.domain. In practice, things can start out different-origin
but become same-origin, if their origins are "related enough". Or start
same-origin and become different-origin.
Second, while Gecko does effectively have a proxy at each Realm boundary
(including same-origin Realms), other UAs do not. As a result, in some
UAs it's possible to get hold of an object that's not same-origin with
you at this moment, if it or other objects related to it were
same-origin with you in the past.
If you do that, then it feels like multiple Vats that share a single execution
thread. We didn't current have that concept in ES, but we probably could.
That's true.
We do need to pin this down in some way, since this is all very much
observable in terms of event ordering, at least for things that can
reach each other, because it matters which things share event queues
with which other things.
Don't multi-process (eg, process per tab, etc.) browsers in fact have multiple
execution threads?
Yes.
So do some single-process browsers (e.g. Presto-based Opera did, I think).
A PromiseReactionJob that is associated with a marked Realm
Are PromiseReactionJobs associated with a Realm at all? If so, how is
that Realm determined?
Regardless, it seems desirable to be able to describe what happens in terms of
the specified Promise/Realm/Job semantics.
Agreed!
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
