5 ms·

> You're giving up scalability massively you’re vastly over estimating the overhead of processes and number of simultaneous web connections. > only to gain a

> You're giving up scalability massively you’re vastly over estimating the overhead of processes and number of simultaneous web connections. > only to gain a minor amount of safety What you’re telling me is performance (memory?) is such a high priority you’re willing to make correctness and security tradeoffs. And I’m saying thats ok, one of those is crashing might bring down more than one request. > one that is virtually irrelevant in a memory safe language Your memory safe language uses C libraries in its process. Memory safe languages have bugs all the time. The attack surface is every line of your program and runtime. Memory is only one kind of resource and privilege. Process isolation is key for managing resource access - for example file descriptors. Chrome is a case study if these principles. Everybody thought isolating JS and HTML pages should be easy - nobody could get it right and chrome instead wrapped each page in a process.

kevincox 1y ago
> you’re vastly over estimating the overhead of processes and number of simultaneous web connections. It's less the actual overhead of the process but the savings you get from sharing. You can reuse database connections, have in-memory caches, in-memory rate limits and various other things. You can use shared memory which is very difficult to manage or an additional common process, but either way you are effectively back to square one with regards to shared state that can be corrupted.
- monkeyelite 1y ago
  You certainly can get savings. I question how often you need that. I just said one of the costs of those saving is crashing may bring down multiple requests - and you should design with that trade off.
simiones 1y ago
Please find one web server being actively developed using one process per request. Handling thousands of concurrent requests is table stakes for a simple web server. Handling thousands of concurrent processes is beyond most OSs. The context switching overhead alone would consume much of the CPU of the system. Even hundreds of processes will mean a good fraction of the CPU being spent solely on context switching - which is a terrible place to be.
- nosefrog 1y ago
  We did that at Dropbox in Python for a while. Though they switched to async after I left.
- monkeyelite 1y ago
  > Handling thousands of concurrent processes is beyond most OS It works fine on Linux - the operating system for the internet. Have you tried it? > good fraction of the CPU being spent solely on context switching I was waiting for this one. Threads and processes do the same amount of context switching. The overhead of processes switch is a little higher. The main cost is memory.
  - ordu 1y ago
    > Threads and processes do the same amount of context switching. Yes, therefore real webservers use a limited amount of threads/processes (in the same ballpark as a number of CPU cores). Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. > The main cost is memory. The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it are O(N) mostly. All these O(N) calculations needs to be completed multiple times per second, the higher the frequency of switching the more work to do. When you have thousands of processes it is the main cost. If you have tens of thousands it starts to bite hard.
    - monkeyelite 1y ago
      > The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? > Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. That’s certainly the popular approach. As I said at the beginning this approach is making a mini operating system with more bugs and less security rather than leveraging the capabilities of your operating system. Once again, im waiting to here about your experience of maxing out processes and after that having to switch to green threads.

kevincox 1y ago

> you’re vastly over estimating the overhead of processes and number of simultaneous web connections. It's less the actual overhead of the process but the savings you get from sharing. You can reuse database connections, have in-memory caches, in-memory rate limits and various other things. You can use shared memory which is very difficult to manage or an additional common process, but either way you are effectively back to square one with regards to shared state that can be corrupted.

monkeyelite 1y ago
You certainly can get savings. I question how often you need that. I just said one of the costs of those saving is crashing may bring down multiple requests - and you should design with that trade off.

simiones 1y ago

Please find one web server being actively developed using one process per request. Handling thousands of concurrent requests is table stakes for a simple web server. Handling thousands of concurrent processes is beyond most OSs. The context switching overhead alone would consume much of the CPU of the system. Even hundreds of processes will mean a good fraction of the CPU being spent solely on context switching - which is a terrible place to be.

nosefrog 1y ago
We did that at Dropbox in Python for a while. Though they switched to async after I left.
monkeyelite 1y ago
> Handling thousands of concurrent processes is beyond most OS It works fine on Linux - the operating system for the internet. Have you tried it? > good fraction of the CPU being spent solely on context switching I was waiting for this one. Threads and processes do the same amount of context switching. The overhead of processes switch is a little higher. The main cost is memory.
- ordu 1y ago
  > Threads and processes do the same amount of context switching. Yes, therefore real webservers use a limited amount of threads/processes (in the same ballpark as a number of CPU cores). Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. > The main cost is memory. The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it are O(N) mostly. All these O(N) calculations needs to be completed multiple times per second, the higher the frequency of switching the more work to do. When you have thousands of processes it is the main cost. If you have tens of thousands it starts to bite hard.
  - monkeyelite 1y ago
    > The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it The person I am having a conversation with is advocating for threads instead of processes. How do you think threads work? > Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp. That’s certainly the popular approach. As I said at the beginning this approach is making a mini operating system with more bugs and less security rather than leveraging the capabilities of your operating system. Once again, im waiting to here about your experience of maxing out processes and after that having to switch to green threads.