Uh oh!
There was an error while loading. Please reload this page.
[wasm] improve startup - #72275
Conversation
ghost
commented
Jul 15, 2022
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
pavelsavara
commented
Jul 15, 2022
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
pavelsavara
commented
Jul 15, 2022
I tested with current and also future! Blazor |
This comment was marked as outdated.
This comment was marked as outdated.
8a1057f to
d319c22Comparepavelsavara
commented
Jul 15, 2022
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1703991 to
d839ef8Comparepavelsavara
commented
Jul 16, 2022
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This is the startup sequence for non-blazor |
657f65b to
d2884fbComparepavelsavara
commented
Jul 17, 2022
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
d2884fb to
2050175Comparepavelsavara
commented
Jul 17, 2022
This is startup sequence with updated blazor |
pavelsavara
commented
Jul 17, 2022
/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
Update: the fix helps, but there is still a problem. I think what's happening is that Which might be because |
lambdageek
commented
Jul 25, 2022
Here's what our |
Ok, so the issue is in this functionrun(args){args=args||arguments_;if(runDependencies>0){return;}if(ENVIRONMENT_IS_PTHREAD){readyPromiseResolve(Module);initRuntime();postMessage({"cmd": "loaded"});return;}preRun();if(runDependencies>0){return;}functiondoRun(){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 stageawaitafterPostRun.promise;// - here we resolve the promise returned by createDotnetRuntime exportreturnexportedAPI;// - 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 forif(!ENVIRONMENT_IS_PTHREAD)awaitafterPostRun.promise;// - here we resolve the promise returned by createDotnetRuntime exportreturnexportedAPI;// - any code after createDotnetRuntime is executed now});With the above change, the diagnostics sample works for me. Maybe we should just return from |
lambdageek
commented
Jul 26, 2022
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. |
pavelsavara
commented
Jul 26, 2022
@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. |
pavelsavara
commented
Jul 26, 2022
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
pavelsavara
commented
Jul 26, 2022
pavelsavara
commented
Jul 26, 2022
@lambdageek when I rebuild with |
pavelsavara
commented
Jul 26, 2022
lambdageek
commented
Jul 26, 2022
| 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); | ||
There is well known There is also timeout on V8+windows edit: maybe this PR surfaced the #72880 |





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