Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

I'm loving the spirit if not the snark, but it's still odd OpenBSD's httpd (not to be confused with Apache httpd) calls it's CGI gateway "slowcgi" (and kindof derides CGI programming). I mean, it being slow is entirely the fault of the O/S isn't it ?: And using C gets a whole level more challenging with long-running processes and async I/O because of manual memory management. Native CGI programming IMHO is best enjoyed with a reverse cache if you can help it, such as with Apache's mod_cache.

View on HN

It's slowcgi.. you know, as opposed to fastcgi. It's just a name. It was implemented so that httpd(8) didn't have to support executing CGI programs itself and could speak only FastCGI.

You don't /have/ to use it, but it's safer.

http://man.openbsd.org/slowcgi

I was referring to the release announcement back in 2014 or so which I'm unfortunately not able to find (there was more than a bit snarkiness towards CGI programming).

I'm aware what FastCGI is ;) Btw. if you're interested in native HTTP I'd be looking into nghttp2 rather than FastCGI and OBSD's httpd.

Edit: see also https://ef.gy/fastcgi-is-pointless and https://news.ycombinator.com/item?id=9202039 (previous discussion of OBSD's httpd)

how can i trust a lib which still uses openssl in this day and age?

httpd(8) only supports the FastCGI protocol. If you want to run your "legacy" CGI programs you need a wrapper. The chosen name for this wrapper is slowcgi(8).

CGI always spawns off an new process for each request, and always was slow compared to FastCGI, so slowcgi(8) seems like a good name.

It's slow because of its design, i.e. spawning a new process for each request; so it's not because of the OS.

I'm not sure that sentence makes much sense though since the O/S is responsible for creating processes after all. There's an inherent overhead in the POSIX process model; but there's also overhead in the kind of manual memory management needed in support for evented I/O considering typical mixed web server workloads.

Is there an OS in which spawning a new process is not relatively expensive (relative to forks and thread pools)?

Reply on news.ycombinator.com