There are a couple of important features still missing from the initial implementation. The most notable is support for local UNIX sockets. At present, only les

There are a couple of important features still missing from the initial implementation. The most notable is support for local UNIX sockets. At present, only less performant (however more flexible) TCP sockets are available. This note hints at a missed opportunity to employ what some like to call "unix factoring": the listen(2) call can occur outside of your FastCGI worker program, which then only has to call accept(2) on the inherited descriptor, and implement the FastCGI protocol. Why do it this way? 1. Beyond the accept(2) call, your worker program is now network agnostic. 2. Guess what, you can now test your worker program by feeding it FastCGI protocol data directly on stdin. Just add a mode that uses stdin instead of the fd returned by accept(2). 3. For easy TCP socket support, run your worker under something like this tiny program [1]. For easy Unix Domain socket support, run your worker under something like this tiny program [2]. Your worker program doesn't change because the networking concern has been separated out. 4. If you want, you can put a program which keeps a preforked worker pool between the the listener program and the worker program. This separates out the concurrency concern. 5. No real performance downside; listen(2) is called once for a long-running server process. [1] tcplisten : https://gist.github.com/acg/4211098 https://gist.github.com/acg/4211098 [2] unixlisten : https://gist.github.com/acg/8016689 https://gist.github.com/acg/8016689