|
|
|
|
|
|
by tsimionescu
409 days ago
|
|
|
> The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? I was certainly not, I explicitly said that thread-per-request is as bad as process-per-request. I could even agree that it's the worse of both worlds to some extent - none of the isolation, almost all of the overhead (except if you're using a language with a heavy runtime, like Java, where spawning a new JVM has a huge cost compared to a new thread in an existing JVM). Modern operating systems provide many mechanisms for doing async IO specifically to prevent the need for spawning and switching between thousands of processes. Linux in particular has invested heavily in this, from select, to poll, to epoll, and now unto io_uring. OS process schedulers are really a poor tool for doing massively parallel IO. They are a general purpose algorithm that has to keep in mind many possible types of heterogeneous processes, and has no insight into the plausible behaviors of those. For a constrained problem like parallel IO, it's a much better idea to use a purpose-built algorithm and tool. And they have simply not been optimized with this kind of scale in mind, because it's much more important and common use case to run quickly for a small number of processes than it is to scale up to thousands. There's a reason typical ulimit configurations are limited to around 1000 threads/processes per system for all common distros. |
|
|
Correction. People who wanted to do async IO went and added additional support for it. The primary driver is node.js.
> And they have simply not been optimized with this kind of scale in mind,
yes, processes do not sacrifice security and reliability. That’s the difference.
The fallacy here is assuming that a process is just worse for hand wavy reasons and that your language feature has fa secret sauce.
If it’s not context switching then that means you have other scheduling problems because you cannot be pre-empted.
> There's a reason typical ulimit configurations are limited to around 1000 threads/processes per system
STILL waiting to hear about your experience of maxing out Linux processes on a web server - and then fixing it with green threads.
I suspect it hasn’t happened.