Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58017
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.215.42 as permitted sender)
Received-SPF: pass (google.com: domain of tom@punkave.com designates 10.112.101.40 as permitted sender) client-ip=10.112.101.40;
MIME-Version: 1.0
In-Reply-To: <CAKOpQSyBtFc6t+yB69+3S-2LY8bghoHNdLzamJD1kjePgzqQHQ@mail.gmail.com>
References: <CAORXhGJWoLbLgX4ur_CuYpj7J28srgBtcO7uTnM5Wt5SYwKD9w@mail.gmail.com>
	<CAKOpQSyBtFc6t+yB69+3S-2LY8bghoHNdLzamJD1kjePgzqQHQ@mail.gmail.com>
Date: Fri, 24 Feb 2012 15:30:17 -0500
Message-ID: <CAORXhGJJAo=-JCWcPgNeHKwvEbTgnDhuAfGMrjgVD7dR=HL7Tw@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
From: tom@punkave.com (Tom Boutell)

Good point. Last I tried that it worked poorly - I couldn't find a
bytecode cache that worked with it, performance was poor - and I
switched to the Microsoft accelerator and IIS. But things may have
changed.

Doesn't really explain it on Linux...

But what I really want to know is just how to get predictable behavior
in my script - after installing a new PHP and pecl I should be able to
do pecl installs and have them show up in the right extensions folder
for the PHP I just built, but no such luck.

(Yes, /usr/local/bin/pecl is the one I just built.)

On Fri, Feb 24, 2012 at 3:08 PM, Kris Craig <kris.craig@gmail.com> wrote:
> As far as Windows is concerned, it is worth noting that the Apache mod_ph=
p
> (i.e. ZTS) build is supported.=A0 Also, though my information is a bit
> outdated, last I heard work was being done to support thread-safe PHP as =
an
> ISAPI module on IIS, though I don't know what the status of that is.
>
> --Kris
>
>
>
> On Fri, Feb 24, 2012 at 11:52 AM, Tom Boutell <tom@punkave.com> wrote:
>>
>> I'm building a script that installs PHP 5.3.10 from source. One of the
>> steps is to install apc and mongo support via pecl. I'm building the
>> CGI/FastCGI version. This is on a box that formerly had mod_php
>> installed.
>>
>> If I do 'make install' of PHP (which installs a new pecl binary) and
>> follow it up immediately with 'pecl install apc', the apc extension
>> winds up here:
>>
>> /usr/local/lib/php/extensions/no-debug-zts-20090626
>>
>> That's not what command line php and php-cgi are looking for, so they
>> produce warnings and don't load the extensions.
>>
>> However If I do the pecl install later - possibly after restarting
>> Apache with fastcgi enabled - it installs to the new, correct place:
>>
>> no-debug-non-zts-20090626
>>
>> The warnings go away, and everything is great.
>>
>> This raises two questions about which no documentation seems to exist
>> after quite a bit of searching and which raise questions about whether
>> PHP is doing sensible things, so I took the liberty of bringing them
>> to folks who actually understand PHP's internals.
>>
>> 1. You only get one pecl binary although you may have many SAPIs
>> installed. mod_php defaults to thread-safe (and there seems to be no
>> way to turn that off on Linux), while php-cgi does not. So how does
>> pecl decide which way to build extensions? I tried setting
>> extensions_dir via config-set, but that setting was ignored (unless
>> perhaps it falls back if the folder doesn't exist yet?). How can I
>> ensure that, having just installed PHP and pecl, my next pecl install
>> will build extensions for the right flavor of PHP?
>>
>> 2. Why does php turn on thread-safety for mod_php at all on Linux,
>> given that it apparently still doesn't work very well with various
>> extensions in a genuinely multithreaded situation, slows things down,
>> takes more memory, and leads to problems like this one?
>>
>> Everyone I've found runs PHP under the Apache prefork MPM, which does
>> not attempt to run PHP in multiple threads of one process. I have
>> never seen anyone successfully use the worker MPM with PHP, except by
>> moving PHP out to a fastcgi process pool, which is, again,
>> single-process PHP.
>>
>> Even Microsoft's PHP accelerator uses the fastcgi-based,
>> one-process-per-PHP-request approach. Since Windows is so
>> thread-oriented that seems significant.
>>
>> I have attached my script.
>>
>> Thanks for any insight!
>>
>> On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov <nikita.ppv@googlemail.com>
>> wrote:
>> > Hi internals!
>> >
>> > I have written an RFC that proposes to *deprecate* and *remove* the /e
>> > modifier:
>> >
>> > https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
>> >
>> > Comments welcome!
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com