[wasm] improve startup #72275
Merged
[wasm] improve startup #72275
Conversation
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
pavelsavara
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
Member
Author
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
I tested with current and also future! Blazor |
This comment was marked as outdated.
This comment was marked as outdated.
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
8a1057f to
d319c22
Compare
Member
Author
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
1703991 to
d839ef8
Compare
Member
Author
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
This is the startup sequence for non-blazor |
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
657f65b to
d2884fb
Compare
Member
Author
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
pavelsavara
force-pushed
the
wasm_improve_startup
branch
from
d2884fb to
2050175
Compare
Member
Author
|
This is startup sequence with updated blazor |
Member
Author
|
/azp run runtime-wasm |
# Conflicts: # src/mono/wasm/runtime/diagnostics.ts # src/mono/wasm/runtime/dotnet.d.ts # src/mono/wasm/runtime/pthreads/worker/index.ts # src/mono/wasm/runtime/startup.ts # src/mono/wasm/runtime/types.ts
Member
|
Threaded sample isn't happy after the merge. I'm investigating repro steps:
|
Member
|
Update: the fix helps, but there is still a problem.
I think what's happening is that Which might be because |
Member
|
Here's what our |
Member
|
Ok, so the issue is in this function run(args) {
args = args || arguments_;
if (runDependencies > 0) {
return;
}
if (ENVIRONMENT_IS_PTHREAD) {
readyPromiseResolve(Module);
initRuntime();
postMessage({
"cmd": "loaded"
});
return;
}
preRun();
if (runDependencies > 0) {
return;
}
function doRun() {
if (calledRun) return;
calledRun = true;
Module["calledRun"] = true;
if (ABORT) return;
initRuntime();
readyPromiseResolve(Module);
if (Module["onRuntimeInitialized"]) Module["onRuntimeInitialized"]();
postRun();
}
if (Module["setStatus"]) {
Module["setStatus"]("Running...");
setTimeout(function() {
setTimeout(function() {
Module["setStatus"]("");
}, 1);
doRun();
}, 1);
} else {
doRun();
}
}So when we do module.ready = module.ready.then(async () => {
// wait for previous stage
await afterPostRun.promise;
// - here we resolve the promise returned by createDotnetRuntime export
return exportedAPI;
// - any code after createDotnetRuntime is executed now
});Because nothing resolved Update it's less misleading to just return from module.ready = module.ready.then(async () => {
// wait for previous stage
// on pthread workers, postRun is never called, so there is nothing to wait for
if (!ENVIRONMENT_IS_PTHREAD) await afterPostRun.promise;
// - here we resolve the promise returned by createDotnetRuntime export
return exportedAPI;
// - any code after createDotnetRuntime is executed now
});With the above change, the diagnostics sample works for me. Maybe we should just return from |
Member
|
As follow-up to this PR we should figure out what kind of JS initialization we want to do in pthread workers. the normal callbacks don't fire. i'm not sure if that's ok or if it's leaving some part of our JS state incorrect. |
Member
Author
|
@lambdageek there is alredy condition in Which is I guess some different issue. If the build is green, I will merge as is and we will continue in follow-up PRs.
|
Member
Author
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
I noticed on the screenshot that the |
Member
Author
|
@lambdageek when I rebuild with
|
Member
Author
|
This is release version |
Member
That's an asssert that we resumed a thread more times than we suspended it. Probably not due to this PR. |
lambdageek
reviewed
Jul 26, 2022
Comment on lines
-356
to
+316
| configure_emscripten_startup(module, exportedAPI); | ||
|
|
||
| if (ENVIRONMENT_IS_WORKER) { | ||
| // HACK: Emscripten's dotnet.worker.js expects the exports of dotnet.js module to be Module object | ||
| // until we have our own fix for dotnet.worker.js file | ||
| // we also skip all emscripten startup event and configuration of worker's JS state | ||
| // note that emscripten events are not firing either | ||
| return <any>exportedAPI.Module; | ||
| } | ||
|
|
||
| configure_emscripten_startup(module, exportedAPI); | ||
|
|
Member
Author
|
There is well known There is also timeout on V8+windows edit: maybe this PR surfaced the #72880 |
10 tasks
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
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.
streaming wasm instantiation, more parallel download of DLLs
and other goodnes seen in Blazor
downloadResource?: (request: ResourceRequest) => LoadingResourceallows Blazor to delegate the details to runtime while keeping the caching responsibility.config.assetscould now haveresolvedUrlandpendingresponse. That's blazor could tell us what to load and also provide pending cache promise.mono_wasm_pre_init_esentialalso in Blazor loader. This will fix subtle crypto for them.mono_wasm_after_runtime_initializedalso in Blazor loader. This would domono_wasm_load_runtime,,mono_wasm_runtime_readyandbindings_lazy_initfor them. This will enable new[JSImport]for blazor.locateFileis now used for all assets includingmono-config.json. I also fixedscriptDirectorydetection on all but v8+CJS. Therefore apps could be executed from different folder than isdotnet.jslocation. Credits to @yamachuinit_cryptoalso on blazor startup sequenceContributes to #70892
Contributes to #72810