Why you can have millions of goroutines but only thousands of Java threads

Re:Why you can have millions of goroutines but only thousand... by benwilson-512 on Monday October 08, 2018 @09:34PM (#18172722)

In Erlang (and presumably Go) green threads end up in a waiting queue when waiting on further work to do, and as such don't need to be polled or consume any CPU at all while idle. It's only when they receive a message indicating more work can be done that they move into the work queue.

[ Parent | on HN ]

Re:Why you can have millions of goroutines but only thousand... by chrisseaton on Monday October 08, 2018 @09:38PM (#18172739)

I think the person you're replying to was saying that 'useful work' does not including waking up, reading one value, and then immediately sleeping again for another response. That's a big expensive context switch for really nothing very useful, and it could have waited until all inputs were ready and there was significant computation that could be run.

[ Parent | on HN ]

Re:Why you can have millions of goroutines but only thousand... by Ndymium on Tuesday October 09, 2018 @06:34AM (#18174738)

In most cases, BEAM's (the Erlang VM's) context switches are not big and expensive, though, which is something you get with user space threads.

[ Parent | on HN ]