On Jan 29, 2013 12:10 PM, "Zeev Suraski" <z...@zend.com> wrote: > > > The other main reason from my side to keep ZTS is Windows. Windows > cannot > > perform well using process based SAPI. > > Windows actually works quite well with FastCGI. So well Microsoft even > created their own version for IIS. It's outperforming the ISAPI module by > a wide margin.
Laziness and design mistake. Everything on windows (AD,IIS, asp.net, etc) uses thread. And no, nuts is not faster. I am not talking about PHP zts, but in general. > Other than Apache/Windows not having FastCGI support(*), I really can't > imagine any situation where using ZTS inside of a Web Server context makes > any sense at all. I wouldn't call it a new trend, it's both old (I've > been pushing for it since at least 2006, probably earlier) and with very > solid technical reasons (faster, more reliable). Miss the rest of my mail or? Current implementation is outdated and slow. > > Yes, TSRM is horrible and does not match modern thread safe > implementation > > (APC does it better for its usage f.e. using rwlock). > > Note that I wasn't talking about the implementation of ZTS, but why you > would want to use it in the first place. I actually think that using > thread local storage is much better than using locks - but if you can make > the whole problem disappear because there's no need for thread safety, > that's even better. Why heavily invest in something unless there's a very > good reason to use it? See what I wrote in my previous reply. Cheers,
