You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.
The current text as it stands doesn't make it clear in which realm the DoAgentFinalization is supposed to run, which then leaves it open which realm is used by the EnqueueJob, which in turn means that it's unclear in which realm the WeakFactoryCleanupJob has to run.
Since WeakFactoryCleanupJob creates JavaScript objects and even calls into arbitrary user code - aka [Cleanup] - which might not even be callable, it has to have some current realm.
One obvious solution here would be remember either the realm or the current execution context on the WeakFactory and enter that realm in DoAgentFinalization for that particular factory.
The text was updated successfully, but these errors were encountered:
@bmeurer This suggestion sounds right to me, and mirrors similar logic in WebIDL (recently made concrete by @Ms2ger). Here, as you say, each FinalizationGroup could have its own [[Realm]] internal slot, which is used to look up the %FinalizationGroupCleanupIterator% when constructing one.
The current text as it stands doesn't make it clear in which realm the
DoAgentFinalization
is supposed to run, which then leaves it open which realm is used by theEnqueueJob
, which in turn means that it's unclear in which realm theWeakFactoryCleanupJob
has to run.Since
WeakFactoryCleanupJob
creates JavaScript objects and even calls into arbitrary user code - aka[Cleanup]
- which might not even be callable, it has to have some current realm.One obvious solution here would be remember either the realm or the current execution context on the
WeakFactory
and enter that realm inDoAgentFinalization
for that particular factory.The text was updated successfully, but these errors were encountered: