[browser][mt] Do not allow blocking on the thread with JS interop: UI, JSWebWorker

[lambdageek]

Blocking synchronization primitives should continue to throw on the

• UI, JSWebWorker threads
• PNSE as they do in single-threaded Wasm

There should be opt-out MsBuild flag, for projects who need to risk it.

[ghost]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	lambdageek
Assignees:	-
Labels:	area-System.Threading
Milestone:	-

[ghost]

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

Issue Details

---

Blocking synchronization primitives should continue to throw on the main thread as they do in single-threaded Wasm

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, area-Threading-mono
Milestone:	-

[pavelsavara]

If we move out of UI thread, the scenario is calling synchronous JSExport across threads.
We could make it throw by default and opt-in into silent spin-wait.

[pavelsavara]

We need to also prevent it for JSWebWorker threads because synchronous .Wait prevents HTTP/WS events, which could lead to deadlock.

cc @radekdoulik

[pavelsavara]

Quick list of APIs, for which we need to validate that they internally use something we already addressed so far.
Or we need to address them too.

• Task - WaitAll, WaitAny, InternalWait
• WaitSubsystem - Wait
• WaitableObject - .Wait, SatisfyWaitForAll, Wait_Locked
• ThreadWaitInfo - .Wait, Sleep,
• LowLevelLock - WaitAndAcquire
• LowLevelMonitor - Wait, Acquire
• LowLevelSpinWaiter - Wait
• LowLevelLifoSemaphore - Wait
• FileSystemWatcher - WaitForChanged
• GC - WaitForFullGCApproach, WaitForFullGCComplete, WaitForPendingFinalizers
• CancellationTokenSource - WaitForCallbackToComplete
• ManualResetEventSlim - Wait
• SemaphoreSlim - Wait
• SynchronizationContext - Wait
• WaitHandle - WaitOne, WaitAll
• ManualResetEventWithAwaiterSupport - Wait
• CountdownEvent - Wait
• Interop.Sys.LowLevelMonitor_TimedWait & SystemNative_LowLevelMonitor_Wait

I'm sure I missed some places.

[pavelsavara]

I'm thinking about the proper solution for synchronous calls from and to JavaScript.

A) synchronous [JSImport] call targeting the same thread JS.

• we know that the this thread is with js interop and so it would not block.

B) synchronous [JSImport] call targeting the different thread JS.

• we know that the target is also thread with js interop and so it would not block.

C) synchronous [JSExport] call targeting the same thread Managed.

• we know that the target is also thread with js interop and so it would not block.

D) synchronous [JSExport] call targeting the different thread Managed.

• this option doesn't exits yet, but it will become interesting when/if we have UI and deputy separated.
• D1) if we throw PNSE on .Wait in deputy, we can make this call, because the target would not be blocking for long
• D2) if we allow .Wait in deputy, we will have to throw on the [JSExport] boundary. This seems more useful to me, from perspective of legacy 3rd party MT codebases.

None of the JSExport/JSImport which return Task are problem, because they are just sending async message.

[pavelsavara]

• when thread is blocked, the emscripten __emscripten_thread_mailbox_await doesn't work because you need to yield to browser loop.
• maybe we could call emscripten_proxy_execute_queue our self ?
• promise resolved on UI, while deputy is blocked, could be propagated to managed via dedicated I/O thread.
  • Via complete_task -> CompleteTask -> tcs.TrySetResult
  • we need to make sure that continuations don't run on I/O thread.

[pavelsavara]

If we allow blocking on the deputy thread, the interaction with sync JS interop would be also affected. Situation D2 above.

[pavelsavara]

when you call sync JSExport from UI thread, the Console.WriteLine will deadlock and also any FS operation!

• that should also throw PNSE
• or we need to figure out how to let emscripten to server it's queue during wait for the sync call to resolve.

[pavelsavara]

_emscripten_proxy_to_main_thread_js needs to throw when UI thread is blocked by calling synchronous JSExport

[pavelsavara]

#99833 implemented the core part of this for JSThreadBlockingMode.ThrowWhenBlockingWait and JSThreadBlockingMode.WarnWhenBlockingWait

The high level expectations are described in

runtime/src/mono/browser/runtime/types/internal.ts

Lines 577 to 609 in b7c3446

	export const enum JSThreadBlockingMode {
	/**
	* Prevents synchronous JSExport from being called from JavaScript code in UI thread.
	* On JSWebWorker synchronous JSExport always works.
	* On JSWebWorker blocking .Wait always warns.
	* This is the default mode.
	*/
	PreventSynchronousJSExport = "PreventSynchronousJSExport",
	/**
	* Allows synchronous JSExport to be called from JavaScript code also in UI thread.
	* Inside of that call blocking .Wait throws PNSE.
	* Inside of that call nested call back to synchronous JSImport throws PNSE (because it would deadlock otherwise in 100% cases).
	* On JSWebWorker synchronous JSExport always works.
	* On JSWebWorker blocking .Wait always throws PNSE.
	*/
	ThrowWhenBlockingWait = "ThrowWhenBlockingWait",
	/**
	* Allows synchronous JSExport to be called from JavaScript code also in UI thread.
	* Inside of that call blocking .Wait warns.
	* Inside of that call nested call back to synchronous JSImport throws PNSE (because it would deadlock otherwise in 100% cases).
	* On JSWebWorker synchronous JSExport always works.
	* On JSWebWorker blocking .Wait always warns.
	*/
	WarnWhenBlockingWait = "WarnWhenBlockingWait",
	/**
	* Allows synchronous JSExport to be called from JavaScript code, and allows managed code to use blocking .Wait
	* .Wait on Promise/Task chains could lead to deadlock because JS event loop is not processed and it can't resolve JS promises.
	* This mode is dangerous and not supported.
	* Allows synchronous JSExport to be called from JavaScript code also in Main thread.
	* Inside of that call nested call back to synchronous JSImport throws PNSE (because it would deadlock otherwise in 100% cases).
	*/
	DangerousAllowBlockingWait = "DangerousAllowBlockingWait",
	}

Throwing in more scenarios is counter-productive.

We can improve it if we hear specific feedback about it.