I've noticed that lots of recent advances in threading are all just ways to avoid context switching of threads and instead handle those switches manually (e.g. "green threads" in Python).
OS-level threads are a crude big hammer way of doing parallelism - want to run a task? Just switch out the whole 8kb of stack, then switch back to a stack that's 99% identical. Cooperative multitasking was always known to be much more efficient if you could ever get it to work safely - but one misbehaving task killed everything
Ironic that with deployment we're moving in the opposite direction - we've decided we really do need the complete isolation of separate VMs/containers and are willing to pay the performance overhead because process separation isn't enough.
Wikipedia agrees with you on the source of the term. Both the M:N and N:1 threading models themselves are older than Java, but the term "green threads" seems to have come from there.
I'm not so sure about the term 'green threads' but the internet was definitely around well before '95. There doesn't seem to be any mention of 'green threads' in available USENET archives before then, for instance. But if you know of one, anywhere, by all means, I'd love to hear about it.
What I was getting at was that around '95 was when the internet was really starting to come into generalized usage and exponentially more information published on the internet at that time than before. So maybe an internet search wouldn't turn up results, not because the term wasn't in existence prior to '95 but because the term wasn't published on the internet prior to '95.
I think MIPS RISC/Os had 'green' threads in the 80's, or I could be mixing it up with Tandem terminology, where Fiber was a constant type, I seem to recall .. either way, the idea of a userspace-managed thread scheme is as old as the hills.
The question has always been: who deals out the work, the OS or the App? and as we can see, the question will continue to be asked, and un-answered, probably ad infinitum ..
I do remember Tandem and/or Wang talking about green (transportable) threads who were okay to suspend/resume across processor units .. I wish I could find more info, but I really do recall the term being applicable way back when ..
It's not just about context switching costs. One advantage to non-preemtable concurrency is that data races are much easier to reason about, because any operation that you know won't block becomes atomic by default (this doesn't apply to all models, eg. ones that have m:n scheduling).
There's also other resource overheads. For example, I would think nothing of spinning up 10000 greenlets/green threads in python. They cost maybe 1KB of memory each. But spinning up 10000 OS threads? That's a little more dicey.
