Yes, but os threads come with overheads during context switches and for sure during the startup/teardown because you have to take a trip to the kernel to do those things. I don't see how it should be the os's business how to do m:n green threads. I think BEAM, for example can do a lot of clever coordination-free scheduling (it implements mutexes which are aware of the scheduling layout and I think don't bother to coordinate if they aren't necessary). In Erlang, the GC is green-thread aware, since green threads in Erlang don't share much memory -- I don't think there is a good generalized way for an OS to know these sorts of things without kneecapping some pl or another.
Arguably a better place for this is the standard library of your (low level) PL. I think rust and zig do this.
Project Loom experimentally proved that the benefit of virtual lies not in its fast context switches, but in the throughput afforded by having so many threads executed at once.
I am aware of GC-aware green threads. They allow you to combine your GC pause and scheduler pause into one. Again, this is not the end of the world, even when you don’t have shared mutable state. If anything, it makes it easier to build a runtime on top of.
> If anything, it makes it easier to build a runtime on top of.
This is not the point. The point is that it would be very difficult to make an OS green thread that is aware of the runtime's GC, given that an OS will probably want to also support non-gc languages.
Arguably a better place for this is the standard library of your (low level) PL. I think rust and zig do this.