<hr /><i>drh added on 2011-11-25 15:31:22 UTC:</i><br />
A reasonable implementation of FastCGI for Fossil would be:

  1.  Capture the FastCGI parameters and query content
  2.  Write the query parameters and content into a temporary file
      formatted as a normal HTTP request
  3.  Use fossil_system() to recursively invoke Fossil to process
      the generated HTTP request, writing the results into another
      temporary file.
  4.  Read back the reply out of the second temporary file
  5.  Reformat and send the reply back to the FastCGI requestor
  6.  Delete the two temporary files.

The above is basically the procedure used to implement the "ui" and
"server" commands for windows, as shown in the
win32_process_one_http_request() function in the winhttp.c source file.  The
main difference is that in the case of the "ui" and "server" commands,
the incoming request is already a valid HTTP request and does not need
to be translated as it is moved in and out of the temporary
files.  So, in other words, a Fossil FastCGI implementation would basically
be the same as the windows ui/server implementation with some extra
coding and decoding logic thrown in.

Note that the above implementation is completely isolated and does
not require any changes to any existing parts of Fossil.  One has
merely to add a new "fastcgi.c" source file that implements the above.
All of the FastCGI decoding and translation and protocol handling would
be contained entirely in that one source file.

I think the only reason for wanting to support FastCGI is so that you
can run Fossil more easily using nginx.  FastCGI won't be any more efficient.
In fact, if you consider the extra encoding and decoding logic that has
to run, FastCGI will probably be less efficient than simply configuring
nginx to relay requests to a running Fossil "server" instance.