Open dkattan opened 1 year ago
Thanks for letting me know. I think there are two issues here:
QueueUserCallback
not being implemented. I started on supporting it in this branch but there are some robustness issues. I'd rather not merge a partially-working solution as that would be even more confusing. So I'll get back to that whenever I can, but don't know when that will be.I'll leave this issue open to track the QueueUserCallback
requirement.
@SteveSandersonMS I worked on PowerShell and WASM. PowerShell need PR to handle WASM, and need two threads at minimum for handling the execution of async methods in the interpreter. I'm waiting for dotnet team to finish the WASM Multithread model. It was added with some raw api at the end of the net7.0 timeline. Their agenda is to use/debug these api to bring multithread to Blazor Wasm.
I was thinking WASI multithread for was never done (because no model) https://bytecodealliance.org/articles/wasi-threads
For one of my projects, I created a temporary workaround due to the lack of threading. By using a custom TaskSchedular, the host thread can repeatability invoke it to process the Task message queue. A custom Delay was implemented in the same fashion, relying on the host to periodically invoke a refresh function that checks the delay list. You can see the host implementation here https://github.com/CalebSerafin/IsolatedCodeHosting/blob/10f0190f44d5dae82b9c59b6d5e2051eeb1775ca/HostForWasmConsole/AsyncIsolateWorker.cs. And wasm app implementation here https://github.com/CalebSerafin/IsolatedCodeHosting/blob/10f0190f44d5dae82b9c59b6d5e2051eeb1775ca/WasmConsoleApp/AsyncHelpers.cs Note, it is anything but tested or optimised, but hopefully should be a good starting point.
For one of my projects, I created a temporary workaround due to the lack of threading. By using a custom TaskSchedular, the host thread can repeatability invoke it to process the Task message queue. A custom Delay was implemented in the same fashion, relying on the host to periodically invoke a refresh function that checks the delay list. You can see the host implementation here https://github.com/CalebSerafin/IsolatedCodeHosting/blob/10f0190f44d5dae82b9c59b6d5e2051eeb1775ca/HostForWasmConsole/AsyncIsolateWorker.cs. And wasm app implementation here https://github.com/CalebSerafin/IsolatedCodeHosting/blob/10f0190f44d5dae82b9c59b6d5e2051eeb1775ca/WasmConsoleApp/AsyncHelpers.cs Note, it is anything but tested or optimised, but hopefully should be a good starting point.
Great timing! I picked back up on this yesterday and hooked my test project to the branch you created here and started debugging this morning. The error I’m getting appears to be related to function mapping/lookup. I’ll hopefully get to dig more into it later today/tomorrow but I was hypothesizing that it could be that maybe we aren’t considering generic arguments Task
Full disclosure I 100% know that what I'm trying to do is bananas, especially given the infancy of this project and do not expect any assistance.
However, I figured I'd post it anyway in the offchance that this is known issue related to wasm's threading capabilities or perhaps something really stupid that I'm overlooking,
Code
Console Output
Exception details
.csproj
global.json
The PowerShell related nuget packages are also using .net 7.0.2
I tried upgrading to .net8 with the PowerShell 7.4 preview but there is a known issue with the depenencies right now preventing the usage of Microsoft.PowerShell.Commands.Utility from being imported (it is referencing an unreleased nuget package).