-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Remove Entrypoint Invoker #31769
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
Remove Entrypoint Invoker #31769
Conversation
src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHost.cs
Outdated
Show resolved
Hide resolved
src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHost.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
only some minor feedback
src/Components/WebAssembly/WebAssembly/test/Hosting/EntrypointInvokerTest.cs
Show resolved
Hide resolved
LoadingApp_DynamicallySetLanguageThrows looks like an actual test failure. |
Hello @TanayParikh! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -119,7 +119,7 @@ async function boot(options?: Partial<WebAssemblyStartOptions>): Promise<void> { | |||
} | |||
|
|||
// Start up the application | |||
platform.callEntryPoint(resourceLoader.bootConfig.entryAssembly); | |||
await platform.callEntryPoint(resourceLoader.bootConfig.entryAssembly); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TanayParikh @pranavkm Does this change the semantics of app startup? It depends on how BINDING.call_assembly_entry_point
behaves, which I can't guess from reading the diff.
I thought that, previously, calling Blazor.start
would return a promise that resolves when the .NET code begins running and yields the thread (e.g., on an await
). Is that still how it behaves, or does it now resolve only when MainAsync
's task completes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be related to the functionality of BINDING.call_assembly_entry_point
specifically. Pinging @lewing for more context on this given dotnet/runtime#44045.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SteveSandersonMS is correct, successfully awaiting that task should give you the exit code, control will return as soon as it can, given that the runtime is currently singly threaded. If your model expects control to yield here before the runtime has exited, don't await the entry point promise. That said, any expectations that the entry point will yield at a specific point are probably weak.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @lewing
In this case, this PR is a breaking change we should fix before preview 4 ships. @TanayParikh I'll follow up separately to coordinate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Description Regression introduced via: #31769 * On Blazor Server, `Blazor.start` returns a promise that resolves when the .NET code starts up and the app becomes interactive * On WebAssembly: * Prior to #31769, `Blazor.start` behaves the same as server (the promise resolves when the app becomes interactive) * Since #31769, `Blazor.start` returns a promise that doesn’t resolve until the .NET app exits, which typically means never, and hence prevents its usage for triggering post-.NET startup logic This PR is meant to revert that specific bit of logic, so that we no longer await the `platform.callEntryPoint` function and thus `Blazor.start` returns a promise that resolves when the .NET code starts up and the app becomes interactive. This now matches the behavior from 6.0-preview3. ## Customer Impact Without this PR we inadvertently introduce a breaking change where the `Blazor.start` promise doesn't resolve until the .NET app exits. This prevents its usage for triggering post-.NET startup logic. ## Regression? - [x] Yes - [ ] No [If yes, specify the version the behavior has regressed from]: Regression from 6.0-preview3 Regressed by: #31769 ## Risk - [ ] High - [ ] Medium - [x] Low [Justify the selection above] Returning the `await` logic to what it was prior to #31769 which was introduced in Preview 4. ## Verification - [x] Manual (required) - [x] Automated: #31997 ## Packaging changes reviewed? - [ ] Yes - [ ] No - [x] N/A Addresses #31971
## Description Regression introduced via: #31769 * On Blazor Server, `Blazor.start` returns a promise that resolves when the .NET code starts up and the app becomes interactive * On WebAssembly: * Prior to #31769, `Blazor.start` behaves the same as server (the promise resolves when the app becomes interactive) * Since #31769, `Blazor.start` returns a promise that doesn’t resolve until the .NET app exits, which typically means never, and hence prevents its usage for triggering post-.NET startup logic This PR is meant to revert that specific bit of logic, so that we no longer await the `platform.callEntryPoint` function and thus `Blazor.start` returns a promise that resolves when the .NET code starts up and the app becomes interactive. This now matches the behavior from 6.0-preview3. ## Customer Impact Without this PR we inadvertently introduce a breaking change where the `Blazor.start` promise doesn't resolve until the .NET app exits. This prevents its usage for triggering post-.NET startup logic. ## Regression? - [x] Yes - [ ] No [If yes, specify the version the behavior has regressed from]: Regression from 6.0-preview3 Regressed by: #31769 ## Risk - [ ] High - [ ] Medium - [x] Low [Justify the selection above] Returning the `await` logic to what it was prior to dotnet/aspnetcore#31769 which was introduced in Preview 4. ## Verification - [x] Manual (required) - [x] Automated: dotnet/aspnetcore#31997 ## Packaging changes reviewed? - [ ] Yes - [ ] No - [x] N/A Addresses dotnet/aspnetcore#31971
Replaces the custom
EntrypointInvoker
in favor of runtime'scall_assembly_entrypoint
which now supportsMainAsync
.Fixes: #30600
Fixes: #31148