[browser][mt] Upgrade emscripten

[lambdageek]

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.

[ghost]

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]

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.

[pavelsavara]

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

[ilonatommy]

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]

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

runtime/src/libraries/System.Private.CoreLib/src/System/Threading/Thread.cs

Line 745 in 72c9b85

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]

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.

[pavelsavara]

Latest
https://github.com/emscripten-core/emscripten/blob/8c81cac1bbae378bc7dde0c21c99602cbaf452d0/src/library_pthread.js#L910-L922

[ilonatommy]

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]

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