On 8/2/16, Stephan Beal <[email protected]> wrote: > > As i recall (but it's been 6 or 8 years), FastCGI works by starting a > single app instance and piping CGI data through it multiple times (for > multiple requests). If that's the case... Fossil relies on the app shutting > down to free memory, and would be incompatible with such a mechanism. Also, > IIRC, FastCGI provides drop-in "replacements" of the read() and write() > calls via macros, but use the wrong signature for (IIRC) the write() > routine (they use a non-const pointer for the source memory, whereas the > real API uses a const one).
SCGI works the same way - it opens a socket to a persistent process and sends multiple requests over to the process. Fossil handles this the same way it handles the "fossil server" command. There is one persistent process that does nothing but accept SCGI requests. For each request, that process forks a separate child to service that request. You can see this better by noting that there is no "fossil scgi" command, but rather a "--scgi" switch on the "fossil server" command. The same logic that deals with HTTP requests also deals with SCGI requests - it just understands a different protocol. Were we to add FastCGI capabilities to Fossil, no doubt there would be yet another "--fastcgi" option on the "fossil server" command. -- D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
