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 toast0 on Tuesday October 09, 2018 @09:17AM (#18175671)

Sorry, I also expected those things that can be translated into non-blocking calls with select-ish apis for readiness to be translated as well -- because it's the right thing to do in this type of environment.

To be more specific, most socket calls should be async + selectish, but file system calls would likely be done as synchronous, because async doesn't generally work for that -- anyway limiting the number of outstanding file I/O requests tends to help throughput.

[ Parent | on HN ]

Re:Why you can have millions of goroutines but only thousand... by zbentley on Tuesday October 09, 2018 @02:26PM (#18178520)

stat() cannot (on platforms I am familiar with) be performed in a selectish/nonblocking way. That call can block forever. Local filesystem access in general is still not async-capable in very important ways.

[ Parent | on HN ]

Re:Why you can have millions of goroutines but only thousand... by toast0 on Wednesday October 10, 2018 @02:00AM (#18182365)

Yes, filesystem calls are going to block -- but putting that into a limited threadpool shouldn't deadlock your system -- you can't do a blocking read on a file, waiting for it to be filled by another thread (unless/until you start playing with FUSE, I guess.

[ Parent | on HN ]