Skip to content

Conversation

@pavelsavara
Copy link
Member

@pavelsavara pavelsavara commented Mar 15, 2024

  • simplify configuration of MT handling of blocking .Wait
    • removed MainThreadingMode and JSThreadInteropMode configuration
  • new Thread.WarnOnBlockingWaitOnJSInteropThread
  • MT unit tests now use ThrowWhenBlockingWait mode

JSThreadBlockingMode now could have following values

PreventSynchronousJSExport - default

  • 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.

ThrowWhenBlockingWait

  • 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.

WarnWhenBlockingWait

  • 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.

DangerousAllowBlockingWait

  • 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).

Contributes to #76958
Contributes to #98652
Contributes to #99951

Fixes #98804
Fixes #97914
Fixes #44622

More scenarios: #93603 (comment)

@pavelsavara pavelsavara added arch-wasm WebAssembly architecture area-VM-threading-mono os-browser Browser variant of arch-wasm labels Mar 15, 2024
@pavelsavara pavelsavara added this to the 9.0.0 milestone Mar 15, 2024
@pavelsavara pavelsavara requested a review from radekdoulik March 15, 2024 19:09
@pavelsavara pavelsavara self-assigned this Mar 15, 2024
@dotnet-policy-service
Copy link
Contributor

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

# Conflicts:
#	src/mono/browser/runtime/loader/config.ts
#	src/mono/browser/runtime/managed-exports.ts
#	src/mono/browser/runtime/types/internal.ts
@pavelsavara pavelsavara requested a review from maraf March 27, 2024 17:58
@pavelsavara pavelsavara marked this pull request as ready for review March 27, 2024 17:58
@pavelsavara pavelsavara requested a review from lewing as a code owner March 27, 2024 17:58
@pavelsavara
Copy link
Member Author

/azp run runtime-wasm

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pavelsavara
Copy link
Member Author

All the CI failures are #99888

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

None yet

2 participants