> To extend this, many people think of "green threads" as lightweight threading mechanisms. That's kind of accurate for many systems, but not always true. If that's the sense that's meant, then OS-native lightweight threads are certainly possible in the future. But there's probably not much reason to add them when user space lightweight concurrency mechanisms already exist, and there's no consensus on which ones are "best" (by whatever metric).
Wouldn't it make sense to implement them kernel-side when looking at how every programming language seems to have to reinvent the wheel regarding green threads?
Green threads (today) aren't a singular thing, the definition is that they're in user space not kernel space. They are implemented in a variety of ways:
Do you imitate a more traditional OS-thread style with preemption, do you use cooperating tasks, coroutines, what? Since there is no singular best or consensus model, there is little reason for an OS to adopt wholesale one of these variations at this time.
The original green threads (from that page) shared one OS thread and used cooperative multitasking (most coroutine approaches would be analogous to this). But today, like with Go and BEAM languages, they're distributed across real OS threads to get parallelism. Which approach should an OS adopt? And if it did, would other languages/runtimes abandon their own models if it were significantly different?
Preemptive threads with growable stacks. There was some discussion around getting segmented stacks into the kernel, but I'm not sure that's the best approach. There might have to be some novel work done in making contiguous stacks work in a shared address space.
I think the reasons green threads can work in languages is that the runtime understands the language semantics, and can take advantage of them. The OS doesn't understand the language and its concurrency semantics, and only has a blob of machine code to work with.
Not really tbh. The Go runtime has a work-stealing scheduler and does a lot of work to provide the same abstractions that pthreads have, but for goroutines.
Erlang runtime has a work stealing scheduler but it has specific constraints like "how to make sure each running execution context gets a fair share of time and can't lock up the VM (I think you can still lock the go VM with an infinite loop)... So each VM has different concerns.
This is no longer an issue now with Go's async preemption. Also, this is less a "language-level concern" and more a consequence of a poor implementation of preemptive scheduling. Moreover, this is something OS threads already support.
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.
Wouldn't it make sense to implement them kernel-side when looking at how every programming language seems to have to reinvent the wheel regarding green threads?