I don't agree with OP about I/O-bound ops, I think if you're looking to green threading, you've taken a wrong approach.
> [0] the Task.Runmethod offloads the provided action to the thread pool, and the await keyword yields control back to the caller until the task completes.
All async code must be in an async call stack, virtual threads are 100% transparent because its the runtime scheduling them so you get a but more control than relying on the yeild of dotnet at least as I see it.
Again I don't see the huge demand for it personally, but I barely touch dotnet too often so take this with a grain of salt.
> I don't agree with OP about I/O-bound ops, I think if you're looking to green threading, you've taken a wrong
It depends in the implementation. In Go for example, all I/O is async and suspend your green thread, replacing it with another runnable green thread.
This works the same as if you managed an event loop on your own for the purpose of I/O, which is the best way to handle I/O outside for regular user space code. Itβs just automatic with your code resembling a simple, blocking scenario.
OPs note on threading would be C# or runtime specific - green threads have no problem with parallelism, with runtimes commonly having a thread per core (or more) and having them all run green threads in parallel.
I don't agree with OP about I/O-bound ops, I think if you're looking to green threading, you've taken a wrong approach.
> [0] the Task.Runmethod offloads the provided action to the thread pool, and the await keyword yields control back to the caller until the task completes.
All async code must be in an async call stack, virtual threads are 100% transparent because its the runtime scheduling them so you get a but more control than relying on the yeild of dotnet at least as I see it.
Again I don't see the huge demand for it personally, but I barely touch dotnet too often so take this with a grain of salt.
[0] https://stackify.com/c-threading-and-multithreading-a-guide-...