search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.66k stars 4.58k forks source link

Blazor WebAssembly Error : Cannot wait on monitors on this runtime. #61308

Open Xyncgas opened 2 years ago

Xyncgas commented 2 years ago

I want to keep talking about this issue. It's in my opinion a bug, hear me out. We can't pause a thread in blazor because it's running on one thread and it's async all the way that was the decision.

but, this affects the portability of codes, even when they followed best practice, while they can target .net standard 2.0 - mono.wasm - blazor they are still going to break.

how about we fix this by, in my opinion I propose defining what happens when you call .wait() either : block the running thread and let people intentionally make this trade off, or making blazor multi-threaded, or simulate async behavior by forcing it to yield control after timeout that's decided by the .net rt

Xyncgas commented 2 years ago

I have to maintain two code base now just because my libraries contains Parallel.For which apparently uses Task.wait(). please take this seriously folks

javiercn commented 2 years ago

@Xyncgas thanks for contacting us.

The browser is a single threaded runtime (except for wasm threads that are not widely supported on all platforms). If a library blocks the main thread, there's no additional thread where work can resume and unblock the blocked thread.

This is not a decision that we made, it's a limitation imposed by the environment.

ghost commented 2 years ago

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

Issue Details
I want to keep talking about this issue. It's in my opinion a bug, hear me out. We can't pause a thread in blazor because it's running on one thread and it's async all the way that was the decision. but, this affects the portability of codes, even when they followed best practice, while they can target .net standard 2.0 - mono.wasm - blazor they are still going to break. how about we fix this by, in my opinion I propose defining what happens when you call .wait() either : block the running thread and let people intentionally make this trade off, or making blazor multi-threaded, or simulate async behavior by forcing it to yield control after timeout that's decided by the .net rt
Author: Xyncgas
Assignees: -
Labels: `area-System.Threading`, `untriaged`
Milestone: -
ghost commented 2 years ago

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

Issue Details
I want to keep talking about this issue. It's in my opinion a bug, hear me out. We can't pause a thread in blazor because it's running on one thread and it's async all the way that was the decision. but, this affects the portability of codes, even when they followed best practice, while they can target .net standard 2.0 - mono.wasm - blazor they are still going to break. how about we fix this by, in my opinion I propose defining what happens when you call .wait() either : block the running thread and let people intentionally make this trade off, or making blazor multi-threaded, or simulate async behavior by forcing it to yield control after timeout that's decided by the .net rt
Author: Xyncgas
Assignees: -
Labels: `arch-wasm`, `area-System.Threading`, `untriaged`
Milestone: -