Re:State of Loom
by balfirevic on Saturday May 16, 2020 @10:36PM
(#23209028)
Win32 fibers would probably not be a good match for potential .NET fibers. From the link in my previous comment, they seem to allocate the stack of the same size as regular OS threads, making them not appropriate for the use case of keeping thousands or more fibers around.
> Runtimes that choose to roll their own green threads, like Go, and I guess now also Java, are effectively stating that their convenience is worth the inability to interface well with async code outside of their runtime.
You'd still be able to interop with async code outside of runtime, you can still model the API as callbacks for the interop purposes where needed.
But yes, interop has sam trade-offs. Which are, IMO, entirely correct trade-offs to make for Go, Java and .NET (and overwhelmingly so). But they are probably not for (as an example) Rust, according to it's goals.
They're definitely not correct for .NET - you forget WinRT. That ecosystem was much more heavily invested in native interop from the get go - COM interop, P/Invoke, various runtime features like unmanaged pointers and unions etc. So once native async became a thing, .NET developers expect to be able to interop with it, as well.
This points at the bigger problem that every implementation of green threads has: it breaks interop unless everybody buys into it. Async/await is fundamentally callback-based, which can be represented nicely even in C ABI - so literally any language that can interop with C, can interop with an async/await model, with execution flow asynchronous throughout the entire chain. Runtimes that choose to roll their own green threads, like Go, and I guess now also Java, are effectively stating that their convenience is worth the inability to interface well with async code outside of their runtime.