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
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.k...@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
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
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
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
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
