3 ms·
An implementation with buy-in across the entire ecosystem and language so that you don’t have some systems using threads and other systems using futures and oth
by zeeboo 7y ago
An implementation with buy-in across the entire ecosystem and language so that you don’t have some systems using threads and other systems using futures and other systems using different reactors, etc.
Also known as the point of the article.
Additionally, that implication is entirely of your own creation. The article explicitly lists many languages besides Go:
> Three more languages that don’t have this problem: Go, Lua, and Ruby.
Perhaps you just have an anti-Go bias?
- millstone 7y agoLast I tried it, if I had a million goroutines calling stat(), Go would attempt to spawn a million kernel threads. So I rolled my own rate limiter, bleh. Is that still the case? (Happy if not) If it is still the case, is there a standard solution or is it up to the app author?
- acln 7y agoIt's up to the application author in that case, unfortunately. stat() enters the kernel and resolves in one shot, so it requires a whole thread. I haven't read into it very carefully, but on Linux, perhaps the new io_uring business is going to change this state of affairs. For now, however, you need a semaphore of your own.