4 ms·
> Again, too low-level. A programmer working with a high-level language should be able to spawn as many green threads as she wants to, and let the language's ru
by perfmode 10y ago
> Again, too low-level. A programmer working with a high-level language should be able to spawn as many green threads as she wants to, and let the language's runtime system handle multiplexing those green threads over OS threads.
Do this in Go and you'll be surprised how quickly you run out of memory.
- catnaroek 10y agoSounds like a reason not to use Go as a high-level concurrent language.
- perfmode 10y agoSounds like infinite threads is wishful thinking.
- catnaroek 10y agoYou understand the difference between “as many green threads as the programmer wants” and “infinitely many threads”, right?
- perfmode 10y agoYes. Not finite. Unbounded. Finite == bounded == pool.
- dllthomas 10y ago> bounded == pool Pool implies pre-allocated.
- catnaroek 10y agoUnbounded isn't the same as infinite. For example, if you have a fair coin, the number of times you have to flip it until you get 5 tails is unbounded but finite. The problem with creating infinitely many threads isn't even space. Even if you had an infinite amount of memory, programs are supposed to complete their tasks in a finite amount of time, so you shouldn't spawn infinitely many threads, because it's an unreasonable thing to want. On the other hand, spawning 100k green threads is a perfectly reasonable thing to want. It's the language runtime's job to multiplex these 100k green threads over 4 or 8 or however many OS threads make sense.