[umvi]

It's generally something like:

1. Configure webserver (apache, lighttpd, etc) to forward certain routes to a particular unix socket (i.e. `/tmp/fcgi.sock`)

2. Create and launch a C/C++ process that links in libfcgi.so (or similar) and has an event loop reading from the same socket (i.e. `/tmp/fcgi.sock`)

After that the webserver will forward incoming requests that match to the C/C++ process over socket.

[jbergens]

And probably add logic to allow the web server to restart the process if it should fail/crash and maybe recycle it ever Nth hour. Bad C++ code could easily make your process crash.

[kijin]

Apache's mod_fastcgi/mod_fcgid used to try and manage its own FastCGI processes, but the result was rather brittle. It was also a non-starter when the FastCGI processes were on a different machine for load balancing purposes.

It's much simpler to use an independent monitoring program to manage your processes than to rely on the web server. Modern init systems can do this for you, or you can use tools like monit. Docker will probably work, too. Node has PM2. PHP has FPM, which can automatically recycle processes on a preconfigured schedule. Not that they need to be recycled, because PHP is very stable these days, but it's just a one-liner in a config file if you need it.

[liveoneggs]

you should use mod_proxy_fcgi now

[ape4]

Would the socket be in /run now?

[umvi]

I don't think it matters too much where it is as long as it is in RAM and both the webserver and fcgi process have read/write permission on it.