-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[browser][mt] Upgrade emscripten #75625
Comments
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsIn a threaded .NET runtime, Emscripten prints this to the JS console even if C# user code doesn't do any threading
This comes from https://github.com/emscripten-core/emscripten/blob/678d7d8881a810d14f52bb3b7e72a8c337b571ba/src/library_pthread.js#L785 which gets called from various pthread primitives that the runtime calls, such as We should try setting
|
I think the message could be supressed in newer versions of emscripten. Should we bump version of emscripten ? |
Do you mean "The log message that emcc will sometime print (for example when auto-building system libraries) can now be completely suppressed by running with EMCC_LOGGING=0" changelog? |
It seems that the situation changed a lot. We have a possibility of config with
Even with jsThreadBlockingMode: "DangerousAllowBlockingWait I cannot observe messages from emscripten logged when block-waiting.Adding <EmscriptenEnvVars Include="EMCC_LOGGING=0" /> would not change anything. I think we could close it.
|
We are not running C# code on UI thread anymore and so the user code would not be blocking.
|
Reproducing blocking during GC's stop-the-world does not sound like an easy thing. Do you have ideas how to force it? I was planning to check if the logs are there, then add that flag and possibly close the thread. |
We can close this one (about emscripten bump). |
In a threaded .NET runtime, Emscripten prints this to the JS console even if C# user code doesn't do any threading
This comes from https://github.com/emscripten-core/emscripten/blob/678d7d8881a810d14f52bb3b7e72a8c337b571ba/src/library_pthread.js#L785
which gets called from various pthread primitives that the runtime calls, such as
pthread_join
orpthread_cond_timedwait
.We should try setting
-s ALLOW_BLOCKING_ON_MAIN_THREAD=false
and investigate whether the blocking operations are really necessary. If fixing the blocking is infeasible, we should consider overridingModule.PThread.emscripten_check_blocking_allowed
to not nag.The text was updated successfully, but these errors were encountered: