-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Comments
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:
The 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. |
whatwg/webidl#135 (comment) would fix this, although my proposal there uses a different name than "current realm". |
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.
The text was updated successfully, but these errors were encountered: