> So the upshot of writing CGI scripts is that you can... ship broken, buggy code that leaks memory to your webserver and have it work mostly alright
Yes. The code is already shitty. That’s life. Let’s make the system more reliable and fault tolerant.
This argument sounds a lot like “garbage collection is for bad programmers who can’t manage their memory”.
But let me add another reason with your framing. In fire/forget programmers get used to crashing intentionally at the first sign of trouble. This makes it easy to detect failures and improve code. The incentive for long running processes is to avoid crashing, so programs get into bad states instead.
> The only way you can really prevent that is by having complete isolation between processes
Yes. That’s the idea. Separate memory spaces.
> What information does this leak
Anything that might be in a resource, or memory. Or even in the resource of a library.
> and why should I be concerned
Accessing leaked information form a prior run is a common attack.
> but if you don't have to, isn't that significantly better?
Long running processes are inherently more complex. The only benefit is performance.
> H’the web server execute stuff in a specific folder inside the document root just seems like a recipe for problems.
As opposed to? All processes have a working directory. What problems come from using the file system?
> cgroups
Yes it’s the same amount of effort to configure.