As far as Windows is concerned, it is worth noting that the Apache mod_php (i.e. ZTS) build is supported. 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 <t...@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....@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 >
