Hi! > Python, for example, is thread safe by default. Extensions developers
Doesn't Python have global engine lock? > It was and still is a lazy and design mistake to have focused on > FastCGI to support PHP on IIS more easily, while everything else in > this stack uses what the whole OS stack does. That is your opinion, which I am afraid many people do not share. I, for example, think that since PHP follows shared-nothing model, it is much more efficient to allow the OS to do the separation than try to simulate what the OS is doing in userspace. The latter would always be less efficient. While thread-locals may allow some workarounds with regard to internal engine data structures, libraries still remain the problem which is hard to deal with unless you let the OS do it. > I never said that FastCGI does not work well. But that doing so will > never allow us to reach the performance we could get using a more > suited implementation. I am still confused as for what exactly is supposed to make threaded implementation much faster than FCGI one. Generally, FCGI has one factor that slows it down a bit - it has one additional data passing stage - but beyond that, we'd have to do the same and probably more if we'd have to lock resources that aren't thread-local out of the box (example: current directory, locales, etc.). > Again, giving up on thread safety is a major mistake. I'd like to hear a good data-backed explanation why. So far in practice NTS setups proven to be more robust without sacrificing performance. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
