Hacker News new | past | comments | ask | show | jobs | submit login

Java had a quite lousy implementation of green threads, that hurt performance more than enabled parallelism. (What isn't explainable by it being early, since there were earlier green threads implementation that didn't suck. Looks like it just wasn't a priority for Java developers.)

There's nothing anywhere restricting green threads to a single OS thread. Most modern runtimes will automatically multiplex the green threads into as many OS threads as your computer can run.




> Java had a quite lousy implementation of green threads, that hurt performance more than enabled parallelism

1:N green threads (which Java had) aren't intended for parallelism and provide none. They provide concurrency only.

M:N green threads (e.g., Erlang processes) provide parallelism.


Java had a mixed model where it could use LWPs or kernel threads, and switched over around Solaris 8 because things like stat() were still blocking and had no async counterpart, so were difficult to deal with.

I dug up this fossil the other day, trying to get a fix from Sun for this very issue:

http://d.hd.org/JavaThreadsCommentToSun19980820.html


Is this solved in Go? A while back Go required programmers to use rate limiters, otherwise it would spawn unlimited kernel threads for blocking syscalls.


It's capped at 10000 threads (configurable). Note that Go uses asynchronous I/O where possible.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: