Lift execution context management out of Runtime#43063
Closed
motiz88 wants to merge 1 commit into
Closed
Conversation
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D53759776 |
b4f1159 to
e8e41bb
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D53759776 |
Base commit: eca78c3 |
e8e41bb to
fa800fa
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D53759776 |
fa800fa to
320f38c
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D53759776 |
320f38c to
9ee88ec
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D53759776 |
Summary: Changelog: [Internal] Moves the responsibility for managing CDP execution contexts out of the Runtime and into the Instance. This includes the responsibilities to: 1. Assign execution context IDs/names 2. Emit events when execution contexts are created/destroyed 3. Route CDP messages to the correct Runtime **Re 1:** We currently assign a *constant* execution context ID, which diverges from V8's implementation but is in line with what Hermes has done so far. I'll follow up separately to assign (locally) unique IDs, since this diff is long enough already. **Re 3:** Right now, the message routing responsibility is mostly theoretical: only one Runtime exists at a time and "routing" can be done by RuntimeAgent simply deciding whether or not to act on a message (since it receives all messages by default and knows its own `ExecutionContextDescription`). True multi-Runtime / multi-context support is firmly a future concern, and we can revisit this ( = probably hoist more logic into Instance) when we get there. In the `ExecutionContextNotifications` integration test we can see that a few minor bugs in the current Hermes-based implementation are fixed, and also that execution context management is now engine-agnostic (so we can use `JsiIntegrationPortableTest` instead of `JsiIntegrationHermesTest`). Reviewed By: huntie Differential Revision: D53759776
9ee88ec to
fdf8036
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D53759776 |
|
This pull request was successfully merged by @motiz88 in e34e7d7. When will my fix make it into a release? | Upcoming Releases |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Changelog: [Internal]
Moves the responsibility for managing CDP execution contexts out of the Runtime and into the Instance.
This includes the responsibilities to:
Re 1: We currently assign a constant execution context ID, which diverges from V8's implementation but is in line with what Hermes has done so far. I'll follow up separately to assign (locally) unique IDs, since this diff is long enough already.
Re 3: Right now, the message routing responsibility is mostly theoretical: only one Runtime exists at a time and "routing" can be done by RuntimeAgent simply deciding whether or not to act on a message (since it receives all messages by default and knows its own
ExecutionContextDescription). True multi-Runtime / multi-context support is firmly a future concern, and we can revisit this ( = probably hoist more logic into Instance) when we get there.In the
ExecutionContextNotificationsintegration test we can see that a few minor bugs in the current Hermes-based implementation are fixed, and also that execution context management is now engine-agnostic (so we can useJsiIntegrationPortableTestinstead ofJsiIntegrationHermesTest).Reviewed By: huntie
Differential Revision: D53759776