I'd like to make sure fastcgi is well supported in 4.3. I spent some time over the weekend working on this and have some patches that I'll try to get into the tree in the next day or so. I haven't commited them yet as I am having problems getting it to work with apache2-win32/mod_fastcgi (a mod_fastcgi configuration issue I'm trying to figure out). I don't have the time however to do any testing on linux with this, and linux also needs build changes (more on this below).
Some months ago I integrated the fastcgi sapi module into the cgi module for a couple reasons. One was the lack of support for a bunch of stuff in the fastcgi module which the cgi module already had. I felt that rather than maintaining the same code/features in two different modules, that a single module would be better. Another reason was that I wanted one executable rather than multiple executables (I still see php-cli and php-cgi seperation as a downside). There is also a somewhat customized libfcgi under sapi/cgi directory. This primarily contains bug fixes for win32, and changes to make the library a better fit for PHP (ie. not calling exit on errors). The build system needs updating to support building this on Linux systems. I'm thinking that --with-cgi-fastcgi would build the cgi/fastcgi module, and --with-fastcgi would build the seperate fastcgi sapi module. --with-cgi-fastcgi should be default when building the php-cgi module, and a --without-cgi-fastcgi available to turn it off. Another option, --libfcgi=<path> to use a library different that the one included in the source tree. One of the items in my uncommited patch is to integrate the last changes that happened in the fastcgi sapi module, which is support for running PHP as a fastcgi socket server. One difference between the to is the way that is initated: php-fastcgi <address:port> php-cgi -b <address:port> If anyone sees any issue with getting this into 4.3 please let me know. A future feature (after 4.3) I want to implement for fastcgi is a multithreaded fastcgi socket server. This would allow for more configurability in how php is used (single process/request, single process/multiple requests), and provide a way to run out-of-process multithreaded php. Shane -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
