Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:44590 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16539 invoked from network); 1 Jul 2009 18:37:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Jul 2009 18:37:31 -0000 X-Host-Fingerprint: 91.123.14.188 unknown Received: from [91.123.14.188] ([91.123.14.188:3248] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/95-24906-BECAB4A4 for ; Wed, 01 Jul 2009 14:37:31 -0400 Message-ID: To: internals@lists.php.net Reply-To: "Gelu Kelunden" References: In-Reply-To: Date: Wed, 1 Jul 2009 21:37:17 +0300 Lines: 52 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Posted-By: 91.123.14.188 Subject: Re: [PHP-DEV] CGI and FastCGI SAPI From: gelu.kelu@gmail.com ("Gelu Kelunden") 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" 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 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 >> >>