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

[2] unixlisten : https://gist.github.com/acg/8016689