Skip to content

Associate Realms with tasks #4342

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

Open
annevk opened this issue Feb 6, 2019 · 2 comments
Open

Associate Realms with tasks #4342

annevk opened this issue Feb 6, 2019 · 2 comments

Comments

@annevk
Copy link
Member

annevk commented Feb 6, 2019

Each task should have a Realm or a way to get to one so it's clear what the current Realm points to when executing it.

@bzbarsky
Copy link
Contributor

bzbarsky commented Feb 6, 2019

Per discussion with @annevk, here's what Gecko implements here.

Gecko effectively has a global (TLS, actually, but in any given thread it's a global) variable pointing to the current realm. This variable can be null to indicate "no current Realm".

Various operations in the JS engine update this value in a stack-like manner, more or less as per the ES spec requirements. The actual behavior is not quite identical to the ES spec in some interesting cases, but that's out of scope here.

For cases that need to affect the concept of "current Realm" when JS is not running, Gecko has several RAII (so stack-lifetime) helpers. These helpers somewhat correspond to what used to be the script settings stack in HTML; I haven't kept up on what's in HTML there now. But for our purposes here, I think there are basically two relevant helpers: AutoEntryScript and AutoNoJSAPI. There are some other helpers, (e.g. for dealing with incumbent scripts), but they're not directly relevant to realms.

AutoEntryScript takes a global object as a constructor argument, and sets up the entry global and incumbent global to point to that object, and the current Realm to be that object's Realm. The destructor restores the state that was there before the constructor ran.

The AutoNoJSAPI constructor clears out the state: no entry or incumbent globals or current Realm. Again, the destructor restores the pre-constructor state.

Web specs may not need something like AutoNoJSAPI; in Gecko it's used to deal with calling into code that can be called both on behalf of script and not and making sure it does the "not script" behavior.

The upshot is that anyone who's going to need a Realm needs to know what global they will want so they can construct the relevant AutoEntryScript.

@domenic
Copy link
Member

domenic commented Feb 3, 2021

whatwg/webidl#135 (comment) would fix this, although my proposal there uses a different name than "current realm".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants