Skip to content
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

Closed
Tracked by #68162
lambdageek opened this issue Sep 14, 2022 · 9 comments
Closed
Tracked by #68162

[browser][mt] Upgrade emscripten #75625

lambdageek opened this issue Sep 14, 2022 · 9 comments
Assignees
Labels
arch-wasm WebAssembly architecture area-VM-threading-mono os-browser Browser variant of arch-wasm
Milestone

Comments

@lambdageek
Copy link
Member

In a threaded .NET runtime, Emscripten prints this to the JS console even if C# user code doesn't do any threading

Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread

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 or pthread_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 overriding Module.PThread.emscripten_check_blocking_allowed to not nag.

@lambdageek lambdageek added arch-wasm WebAssembly architecture area-VM-threading-mono labels Sep 14, 2022
@lambdageek lambdageek added this to the 8.0.0 milestone Sep 14, 2022
@ghost
Copy link

ghost commented Sep 14, 2022

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

In a threaded .NET runtime, Emscripten prints this to the JS console even if C# user code doesn't do any threading

Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread

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 or pthread_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 overriding Module.PThread.emscripten_check_blocking_allowed to not nag.

Author: lambdageek
Assignees: -
Labels:

arch-wasm, area-Threading-mono

Milestone: 8.0.0

@pavelsavara
Copy link
Member

image

This is how mono thread pool joins threads in order to finalize them.

Other significant use is mono_os_mutex_lock which is used in about 40 places

  • GC
  • threadpool
  • debugger
  • mini

I think that we are unlikely to be able to remove it.
Alternate strategy could be to run mono always on the worker.

@lewing lewing modified the milestones: 8.0.0, 9.0.0 Jul 24, 2023
@pavelsavara pavelsavara changed the title [wasm-mt] papercut: Emscripten warns about blocking on the main thread even if user code doesn't [browser][mt] Emscripten warns about blocking on the main thread even if user code doesn't Nov 9, 2023
@pavelsavara pavelsavara added the os-browser Browser variant of arch-wasm label Nov 9, 2023
@pavelsavara
Copy link
Member

I think the message could be supressed in newer versions of emscripten.

Should we bump version of emscripten ?
Should we also switch to using https://github.com/dotnet/emscripten/ in our inner loop ?

@radekdoulik @lewing

@pavelsavara pavelsavara changed the title [browser][mt] Emscripten warns about blocking on the main thread even if user code doesn't [browser][mt] Upgrade emscripten Jan 26, 2024
@ilonatommy
Copy link
Member

ilonatommy commented Jul 25, 2024

I think the message could be supressed in newer versions 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?

@ilonatommy
Copy link
Member

It seems that the situation changed a lot. We have a possibility of config with jsThreadBlockingMode: "WarnWhenBlockingWait" that produces only our own warning from

var st = $"Blocking the thread with JS interop is dangerous and could lead to deadlock. ManagedThreadId: {Environment.CurrentManagedThreadId}\n{Environment.StackTrace}";
.
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.

@pavelsavara
Copy link
Member

We are not running C# code on UI thread anymore and so the user code would not be blocking.
It could still happen because we stop-the-world during GC.

jsThreadBlockingMode is about something slightly different.

@ilonatommy
Copy link
Member

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.

@pavelsavara
Copy link
Member

We can close this one (about emscripten bump).
The remaining issue will be solved by not blocking UI thread #100411 I updated it to also mention the message

@github-actions github-actions bot locked and limited conversation to collaborators Aug 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-VM-threading-mono os-browser Browser variant of arch-wasm
Projects
Status: Done
Development

No branches or pull requests

6 participants