Re: CGI and FastCGI SAPI

On Jul 1, 2009, at 2:37 PM, Gelu Kelunden wrote:

I think that the official FastCGI implementation will eventually evolve into something like PHP-FPM, if not even more. What I'm saying is that code that handles daemonization (uid/gid/chroot/log), workers mgmt (spawing/safe-shutdown), daemon config file (not php.ini or php-cgi.ini) should not be present in the pure CGI SAPI implementation, but in a different FastCGI-only SAPI.

This seems to me as if it would be a step backwards. For a long time CGI and FastCGI were highly separate setups; you had to use configure flags to enable FastCGI, and so forth. In 5.3 they were unified completely: you can't have one without the other anymore. Why would you need to? -- Gwynne

"Michael Shadle" <mike503@gmail.com> wrote in message news:bd9320b30907011117q4fc2c2c3hbffbf289679e6b9a@mail.gmail.com...

I think it would be a good idea to also include PHP-FPM in your investigation. On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelunden<gelu.kelu@gmail.com> wrote:

Hi, I'm trying to understand how difficult it is to create a new SAPI, so I started to poke my nose inside the "cgi" SAPI source code. I saw that "cgi_main.c" implements both the CGI and the FastCGI protocols and I kinda got lost inside all those if-else lines (I tried to take out the FastCGI code and failed miserably). I'm wondering if it's not better to have 2 different SAPIs, one for CGI and for FastCGI. Advantages of this "split" would be: - the source code will be more readable without all those if-else statements - we would have 2 executables that do 2 different jobs, unlike now where php-cgi does both; each executable could then be further optimized for the exact job they are performing Disadvantages I see: - maintaning 2 SAPI implementaion would require more work (since CGI and FastCGI both share most of the SAPI code, any change would have to be replicated twice) - break backward compatibility (where php-cgi handles both CGI and FastCGI) Thank you for your time, Gelu