hi Zeev, On Tue, Jan 29, 2013 at 10:03 AM, Zeev Suraski <z...@zend.com> wrote:
> Which brings me to the subject of this mail – why are you using ZTS PHP > instead of single threaded PHP? The reasons not to use it are few but > fairly major – it’s significantly slower than the non-ZTS PHP, and it’s > significantly less robust in the sense that a single bug somewhere can > bring down an entire server (or at least a bunch of many different > threads). What are your reasons to choose it over FastCGI? There are situations where FPM/FCGI are not appropriate, or the server used does not support NTS (Apache windows for example, when fcgi is not an option). However, in the long run, I would like to kill TSRM altogether, moving the file/IO related parts where they should be implemented, either the engine or main. Does it mean we will kill thread safety by doing so? No. My idea is to replace it with LTS (thread local storage) which drastically reduce the thread safety issues due to its exact nature, store local thread data per thread and not per process. Issues include well know crashes due to non thread safe code (almost none left in core, but some libs have issues) and brings a huge performance improvement. The other main reason from my side to keep ZTS is Windows. Windows cannot perform well using process based SAPI. It won't match linux as long as it runs within a webserver using a process based implementation (but CLI does not match linux performance and is even faster in a couple of use cases). I've made some tests to write new ISAPIs for IIS8 and with the httpkernel (1). The performance are very promising, given that it is still only a proof of concepts. Having an ISAPI also allows a tighter integration to IIS8 (pipelines, auths, scripting, etc.), which is not possible to do now using fastcgi (no direct access but using RMI or the IIS shell, but horrible, in all possible ways). Conclusion: Yes, TSRM is horrible and does not match modern thread safe implementation (APC does it better for its usage f.e. using rwlock). However it would be a very bad idea to give up on thread safety only because the relatively new trend is all about single threaded/process based implementation. These systems have limits and I'm sure we will see some big change in this area in the couple of years. TLS will let us to do the transition and we can 'easily' support extension developers to port their extensions. (1) similar to our builtin webserver except that it can be used in production servers. It is what IIS used under the hood. Having a SAPI relying directly on HttpKernel will allow one to create many app pools using PHP only. It will work smoothly even if IIS runs on the same host, sharing the same IPs or ports, even the cache will work. Cheers. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
