3 ms·

Are there any advantages to CGI talking to another process (IPC I guess?), or is it just serving traffic with a long-lived process, but with extra steps?

kevincox 3y ago
Basically a long-lived process with extra steps. But if all it does is hold a few file descriptors open it can minimize your long-lived state (which can reduce bugs) and in-use memory between requests.
elric 3y ago
Aside from simplicity, there aren't any major advantages AFAIK. Even in 2024, it only takes about 5 minutes to set up a system with Lighttpd and CGI. When all you have to do is expose an existing binary over the web, then HTTP<->CGI<->Binary is pretty convenient. Just write a tiny CGI wrapper and you can call it a day. Edit: missed a bit of context, so here's a more relevant answer: Long lived process with extra steps, yes, but the key part is that the CGI binary (and the webserver) are sacrificial. They handle input validation and all that nasty stuff, while the real application is safely tucked away. If the CGI binary dies, or the web server crashes, things become unreachable but otherwise operational. It's occasionally a useful characteristic.
vidarh 3y ago
Depends how much you push over the process boundary. The main benefit of a CGI model is guaranteed cleanup of resources, so the more you keep in the CGI side of that boundary, the less potential you have for resource leaks, or data leaking between requests. If you just push your entire app into a long lived process you gain nothing. If you e.g. "only" use it to cache resources that are slow to obtain access to (e.g. connections to slow starting resources, data that is slow and expensive to parse), then it could be a win. But it's been years since the last time I felt that win was sufficiently worth it to design a system that way. In theory, I still love the idea of a guaranteed clean slate, but I'm not willing to give up the slow starting language runtimes I prefer today (e.g. Ruby) for the sake of it.

kevincox 3y ago

Basically a long-lived process with extra steps. But if all it does is hold a few file descriptors open it can minimize your long-lived state (which can reduce bugs) and in-use memory between requests.

elric 3y ago

Aside from simplicity, there aren't any major advantages AFAIK. Even in 2024, it only takes about 5 minutes to set up a system with Lighttpd and CGI. When all you have to do is expose an existing binary over the web, then HTTP<->CGI<->Binary is pretty convenient. Just write a tiny CGI wrapper and you can call it a day. Edit: missed a bit of context, so here's a more relevant answer: Long lived process with extra steps, yes, but the key part is that the CGI binary (and the webserver) are sacrificial. They handle input validation and all that nasty stuff, while the real application is safely tucked away. If the CGI binary dies, or the web server crashes, things become unreachable but otherwise operational. It's occasionally a useful characteristic.

vidarh 3y ago

Depends how much you push over the process boundary. The main benefit of a CGI model is guaranteed cleanup of resources, so the more you keep in the CGI side of that boundary, the less potential you have for resource leaks, or data leaking between requests. If you just push your entire app into a long lived process you gain nothing. If you e.g. "only" use it to cache resources that are slow to obtain access to (e.g. connections to slow starting resources, data that is slow and expensive to parse), then it could be a win. But it's been years since the last time I felt that win was sufficiently worth it to design a system that way. In theory, I still love the idea of a guaranteed clean slate, but I'm not willing to give up the slow starting language runtimes I prefer today (e.g. Ruby) for the sake of it.