-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
concern about multiple set of intrinsics synchronously accesible #262
Comments
Thanks for raising these concerns, @caridy and @domenic .
|
My suggestion is to explore a way of addressing the use cases that does not involve creating new realms, but instead allows new copies of the intrinsics to be created within the same realm. (And then, introduce some modified version of The extensive problems with this proposal all stem from trying to introduce new realms, which has knock-on effects across the ecosystem due to realms being extremely tightly integrated with hosts. (They were the very first host integration point in ECMAScript history.) If you can instead address the use cases entirely inside the ECMAScript machinery, without crossing over into host machinery like realms, that would avoid a huge class of problems. |
I don't understand what it would mean to allocate a new copy of intrinsics in the same Realm. Would they point to each other, or to the original one? |
That'd be up to TC39 to define. The main point is that their [[Realm]] would be the same as the existing ones. |
Overall, does this mean that the observable semantics within in JS would be the same, just that hosts would be unable to see what is the "current" intrinsics set? Aside from that, I'm having trouble understanding what the difference in semantics is. |
I mean, anything keyed off of [[Realm]] would be observably different. |
From what I can see, uses of [[Realm]] in the JS spec that are observable from pure JS lead to the right intrinsics being chosen. So, if there's a form of
Overall, I'm having trouble understanding what the observable effects would be of the change you're proposing. |
It would affect all web platform specs and APIs which key off of realms. This includes both directly script-observable ones, some (but probably not all) of which are mentioned in whatwg/html#5339 (comment), and also specification machinery such as the hierarchy of user agent -> agent clusters -> agents -> realms and how realms are always assumed to either be windows, workers, and worklets. It would also ensure realm-scoped things like base URLs / module maps / cross-origin isolated and other security states / origins are not mucked with by the new thing, since the new thing is only a set of intrinsics, and is not a full realm which brings along all of those. |
I believe this issue has now the same challenge I pointed out at #261. The new Callable Boundary API would not provide access to the different set of intrinsics, as long a separate module graph is preserved. |
No, I believe this can now be closed. There is no more access to a new set of intrinsics. |
@domenic raised this concern during a conversation today. From what I gathered:
Function.prototype.bind
, which creates a new function from another realm, that in conjunction with APIs likepostMessage
, could cause issues.TBH, I still don't fully understand the problem, mostly because the flip side of this is what the associated realm is used for when post messaging? and whether or not the "forwarding" mechanism that @littledan has been working on helps with this? considering that the window and the newly created realm acted as a group "sharing" the settings.
Object.prototype
,Function.prototype
, etc.We have thought about this issue a lot, it is what we call "identity discontinuity hazard", and it is a real hazard for developers, but we have learned to deal with it. In nodejs, this problem is very common. In the web, same domain iframes exhibit the same issue as well. It is something that can be solved with a "near membrane". But I do acknowledge that adding yet one more way to have this issue in the web is concerning.
@domenic also suggested some other areas of explorations here, if the main goal is to have a new set of mutable intrinsics. Something more aligned with a powerful evaluator that can give you the controls to resolve what reference to use during evaluation of code or modules. This sounds a lot like the parameterized evaluator that we have discussed extensibly, and somehow has mutated into the container's proposal. I am up for experimenting in this area.
The text was updated successfully, but these errors were encountered: