CGI and FastCGI SAPI View as Markdown

Any way you guys decide to do it, I think taking learnings and/or code
directly from PHP-FPM could be key to base this off of.

One suggestion might be improving the hooks into PHP so that the
process management component can be done separately. This would allow
for distributions to send it as a separate package and the
configuration portion of the FPM can be done in "userland" as opposed
to PHP internally. PHP just needs the hooks into it.

I've already got the following folks in related discussions, which I
believe are the key players in who can help make the decisions on what
to adopt, etc.

Stanislav Malyshev
Dmitry Stogov
Andrei Nigmatulin
Andi Gutmans

Just waiting to have the rubber hit the road and determine the next steps.

Another benefit to adding only the required hooks into PHP core and
keeping FPM in PECL or something else is so that the adaptive process
spawning, angel process creation (which I think would be required for
adaptive monitoring) and other features that never got finished or I'd
like to see implemented could be implemented independent of PHP
development, and PHP core would only need to be patched if something
required a new hook that a PECL/external module or controller could
not handle.

I'd rather see it done in that fashion probably, as waiting for the
next even minor version of PHP for certain FPM features might take a
while, and I have a "wishlist" which I'd like to turn into a "roadmap"
for the FPM functionality, and PHP has a large codebase that can't
move as fast as I'd like for FPM if it was just merged directly in.

Actually I see it a step forward.

In the beginning, the "cgi" SAPI implemented only the CGI protocol. Support
for FastCGI was added gradually on top of the pure CGI implementation. In
order to test this "non-stable" code, one would have to use
"--enable-fastcgi".

Now FastCGI code is stable enough (and also FastCGI got more widespread and
now is "the" way to do it) to be built by default. And, as of 5.3.0, you
cannot build a CGI-only executable anymore.

New features will definately be added to the FastCGI implementation and I
this it might be good to make the FastCGI SAPI stand-alone and not keep
arround the CGI-only legacy code.

Gelu

"Gwynne Raskind" gwynne@darkrainfall.org wrote in message
news:96158496-0C9A-4568-9A74-2D606730D09A@darkrainfall.org...

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 Kelundengelu.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