Repository navigation
Blazor client developers can use Parallel.For in their applications to share more code with server #43411
Description
Description
Hi,
So the Roslyn compiler is kind of working in blazor wasm with the latest version (3.8.0-4.final) which is great! Appears the hashing issues are fixed. However, now I find there is a strange bug whereby I receive a multi threading exception under the following scenario:
- Dotnet run
- Load web page in browser
- Run compile (works fine)
- Refresh page in browser
- Run compile (exception)
Strangely it works if I close the original tab and open a new one.
Thanks
Configuration
- .NET 5.0.100-rc.2.20479.15
- Blazor wasm
- Microsoft.CodeAnalysis 3.8.0-4.final
- Chrome
Regression?
Last time Roslyn was working in the browser was with Blazor Webassembly 3.2.1 and Microsoft.CodeAnalysis 3.6.0
Other information
System.PlatformNotSupportedException: Cannot wait on monitors on this runtime.
at System.Threading.Monitor.ObjWait(Boolean exitContext, Int32 millisecondsTimeout, Object obj)
at System.Threading.Monitor.Wait(Object obj, Int32 millisecondsTimeout, Boolean exitContext)
at System.Threading.Monitor.Wait(Object obj, Int32 millisecondsTimeout)
at System.Threading.ManualResetEventSlim.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.SpinThenBlockingWait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.InternalWaitCore(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.InternalWait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Wait()
at System.Threading.Tasks.TaskReplicator.Replica.Wait()
at System.Threading.Tasks.TaskReplicator.Run[RangeWorker](ReplicatableUserAction`1 action, ParallelOptions options, Boolean stopOnFirstFailure)
at System.Threading.Tasks.Parallel.ForWorker[Object](Int32 fromInclusive, Int32 toExclusive, ParallelOptions parallelOptions, Action`1 body, Action`2 bodyWithState, Func`4 bodyWithLocal, Func`1 localInit, Action`1 localFinally)
at System.Threading.Tasks.Parallel.For(Int32 fromInclusive, Int32 toExclusive, ParallelOptions parallelOptions, Action`1 body)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.GetDiagnostics(CompilationStage stage, Boolean includeEarlierStages, DiagnosticBag diagnostics, CancellationToken cancellationToken)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.GetDiagnostics(CompilationStage stage, Boolean includeEarlierStages, CancellationToken cancellationToken)
at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CompileMethods(CommonPEModuleBuilder moduleBuilder, Boolean emittingPdb, Boolean emitMetadataOnly, Boolean emitTestCoverageData, DiagnosticBag diagnostics, Predicate`1 filterOpt, CancellationToken cancellationToken)
at Microsoft.CodeAnalysis.Compilation.Emit(Stream peStream, Stream metadataPEStream, Stream pdbStream, Stream xmlDocumentationStream, Stream win32Resources, IEnumerable`1 manifestResources, EmitOptions options, IMethodSymbol debugEntryPoint, Stream sourceLinkStream, IEnumerable`1 embeddedTexts, CompilationTestData testData, CancellationToken cancellationToken)
at Microsoft.CodeAnalysis.Compilation.Emit(Stream peStream, Stream pdbStream, Stream xmlDocumentationStream, Stream win32Resources, IEnumerable`1 manifestResources, EmitOptions options, IMethodSymbol debugEntryPoint, Stream sourceLinkStream, IEnumerable`1 embeddedTexts, Stream metadataPEStream, CancellationToken cancellationToken)
Reacted by Effy Teva
Activity
danmoseley commentedon Oct 14, 2020
I think this is by design -- Roslyn uses mechanisms that rely on mutexes, and those aren't supported on Blazor.
@marek-safar given there's only one thread in WASM, as I understand it, is there any kind of cooperative multithreading support, such that a mutex could work?
andersson09 commentedon Oct 14, 2020
@danmosemsft But why would it work on first page load? Also to note it works when you close the original tab and create a new one.
danmoseley commentedon Oct 14, 2020
I am guessing that if no task is already in progress, it has a special path that does not bother to check the mutex.
marek-safar commentedon Oct 15, 2020
Although
System.Threading.Monitor.Waitis unsupported API on wasm I'm reluctant to simply mark the issue as by design. We haveParallel.Forimplementation which does not work on wasm with no warning to the developers which is not great.There two different solutions I can think of
@jeffhandley @buyaa-n I'm concern that #43363 did catch this issue. Could you please investigate why?
andersson09 commentedon Oct 15, 2020
@marek-safar I think it would be beneficial to go with the first option (of course I would say that :) ). The roslyn api is so close to working perfectly under wasm and I think a significant number of users are using this api within the browser. Would marking the API as unsupported mean even the features that were working wouldn't work?
Perhaps adding an option as an input parameter to disable multithreading could also work?
34 remaining items
[-]Blazor wasm app should be able to use Parallel.For[/-][+]Blazor client developers can use Parallel.For in their applications to share more code with server[/+]RChrisCoble commentedon Nov 30, 2020
It almost sounds like you should just support this instead:
Real multithreading (on supported browsers) #17730
ikeough commentedon Dec 2, 2020
Our issue is exactly the opposite of @andersson09's, and happens in a different place, but seems to have the same root cause. Our call to
CSharpCompilation.CreateScriptCompilationsucceeds but the first time we try to doCSharpCompilation.GetDiagnosticsfollowing the compilation call we get theCannot wait on monitors...exception (stack trace below). The second time we execute this exact same code path, it succeeds without throwing an exception.The solutions proposed above to "fix"
Parallel.Forseem like they would fix this issue as well, but it would be nice to have a work-around. I see the work-around proposed here, but that doesn't help those of us who aren't callingParallel.Fordirectly. Perhaps the ability to pass through theParallelOptionsfor all theCSharpCompilationmethods that internally useParallel.For, would enable us to use the proposed work-around.ivan-prodanov commentedon Mar 3, 2021
Guys, could you please help me find out how this issue was fixed? I sense this was fixed specifically and only in Blazor.
My non-blazor wasm app has the same issue as OP. If I move the code to a blazor app it works just fine. In my non-blazor wasm app I get the same error "Cannot wait on monitors on this runtime.".
Was the issue addressed in Roslyn itself? Where's the fix?
danmoseley commentedon Mar 3, 2021
@lewing ?
marek-safar commentedon Mar 4, 2021
The issue is not yet fixed. It's planned for .NET6 release with Priority 2 (see the labels).
ivan-prodanov commentedon Mar 5, 2021
@marek-safar @lewing It most certainly is fixed in Blazor .NET 5, because you can use Roslyn. I've checked it, it does use Parallel.For inside GetDiagnostics (concurrentBuild option on CSharpCompilationOptions is true).
The easiest way to reproduce this without Roslyn is to call this C# code anywhere from js "Parallel.For(0, 10, i => Console.WriteLine(i));". It works only in Blazor apps.
lewing commentedon Aug 17, 2021
We've landed an implementation in #57283 once @kg has opened a tracking issue for the follow-up this can be closed.
lewing commentedon Aug 17, 2021
#57580