Re: pecl, zts, non-zts, fastcgi and Apache

From: Date: Sat, 03 Mar 2012 12:46:01 +0000
Subject: Re: pecl, zts, non-zts, fastcgi and Apache
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.internals 
Request: Send a blank email to internals+get-58546@lists.php.net to get a copy of this message
On 29.02.2012 10:43, jpauli wrote:
On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joye<pierre.php@gmail.com> wrote:
hi Bill, On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote:
On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
On 02/28/2012 02:44 PM, Christopher Jones wrote:
Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure'
Why punish everyone by default because of Apache? Does not make sense
to
me.
What is so difficult to grok about
Nothing, but it is easier to get a point when the rhetorical comments are removed :)
1. setting up php-cgi to use fastcgi as the httpd default. 2. having parallel non-zts and zts installs of php (notably with only
    non-zts cli and cgi sapi's) with two different lib paths.  Multiply
    by two again if you have parallel i686 and x86_64 installs.
All of these are packager's questions anyways, as so few users do this for themself, most hosters aren't rebuilding php either.
Right, and that's a rather big change, package wised. While the lbraries (systems) are the same, at lest for 99.99% of them. There are a few which can be built in TS or not TS mode but I don't think it is worth it.
PHP would be a much nicer, friendly and more civilized development list if it borrowed only one phrase from the Perl community; TMTOWTDI.
Civilized sounds very wrong in this context, or in general these days. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Right, I suggest we leave #61172 as is, as it solves the problem. PHP should be built with whatever MPM has been detected at configure time (httpd -V) , and that's all. The work of switching MPM later should be left to package maintainers, and scripts like Debian's "a2enmod" which can handle that themselves.
You could in fact add a safety net by querying the threadedness of the MPM during mod_php startup. There's a standard MPM query API in Apache, which tells you whether a threaded MPM is in use. If the mod_php build would be without thread support and the module detects a threaded MPM during startup, it could prevent startup of Apache and output an error message. Regards, Rainer

« previous php.internals (#58546) next »