4 ms·
You are correct that there is an awful lot of software that came out of the 90s that was explicitly written for forking/multiple processes (we're talking 25-30
by eyberg 5y ago
You are correct that there is an awful lot of software that came out of the 90s that was explicitly written for forking/multiple processes (we're talking 25-30 years now) but that only reflects the type of commodity computers we had then - pre SMP, pre commercialized virtualization, pre-cloud, etc. Threads back then weren't in a useable state either.
Fast forward to today and we're finally starting to see the tide turn. I can go spin up a 384 thread instance on gcp right now. We have very popular languages like go and rust. In the case of Go they've made multi-threading easily accessible to many developers to the point that many people don't even think about it.
Yes, there's a lot of cruft out there but we can build for the future.
- toast0 5y agoIf you don't actually need shared anything but config (memory / fds / task pooling), pre-fork is still better than threading. 384 threads sitting on one fd table is going to bottleneck on open (and maybe close) and anything else that is a lock per process.
- eyberg 5y agoI'd disagree here. You can create a thread pool that matches your pre-fork env as well and it will still be vastly more performant especially in those environments that require more memory - which is many applications today.