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.
Gelu
"Michael Shadle" <mike...@gmail.com> wrote in message
news:bd9320b30907011117q4fc2c2c3hbffbf289679e6...@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.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 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
