If you took everything you heard for granted, you'd have been lead to believe that the official PHP distributions (from php.net) have been thread-safe since version 5.2.0.
That's not true. Don't fall for it. Don't attempt to use PHP in a multi-threaded environment (mpm_worker on Apache, ISAPI on IIS, etc.), because PHP thread-safety is a myth.. nothing more than a bunch of lies, if you will.
If you look at the PHP download page, you'll see that the pre-built binaries (in this case, Windows) are split into two: thread-safe and non-thread-safe:
The problem is, no matter which you choose, PHP isn't thread safe. You'll still get the same, old, dreaded "PHP has encountered an access violation at memory_address" error.
It's not a question of server configuration so much as it is one of PHP writing bad code and pretending that's not the case. PHP isn't multi-threading ready and most everyone knows it... but it seems they still feel the need to pass it off as if it were, never mind the complaints and bug reports that come.
There isn't a known solution to this problem. The source code for the official PHP distribution is simply not re-entrant and isn't capable of being used in multi-threaded environments. It's filled with race conditions and lacks the proper monitors/locks on shared memory spaces (which needn't be shared in the first place). Unfortunately, there's not much more to be said; making this post more of a rant than a guiding light for those of you experiencing this issue.
At NeoSmart Technologies we still recommend the only other production-ready, decently-performing *sapi alternative; which is the deployment of PHP by means of the FastCGI protocol. Whether on Linux or Windows, FastCGI scripting engines are considerably faster than their age-old CGI implementations (though the outcome is more-clearly felt on Windows where the CGI model is hideously slow). But we've already discussed this before, countless times.
The moral of the story is that PHP isn't multi-threaded - yet if you go by what they say, you'd come to think it was... until you try it out for yourself and realize that not a darn thing has changed in the 5.2.x releases when it comes to thread-safety and the deployment of PHP in multi-threaded environments.
If you still insist on using ISAPI implementations, you should probably use the latest versions of the PHP4 distribution instead. The older PHP line is less-apt to cause an access-violation error on your machine, and will more than outclass the PHP5 "thread-safe" distributions when it comes to reliability.
PHP needs to clean up their act and either produce real (and verifiably so) thread-safe, re-entrant code or stop the false propaganda that would lead you to believe it's thread-safe in its current incarnation - especially when most other dynamic scripting languages (such as Perl) have proper, thread-safe engines available.
Yeah, this is so true. More than once I've filed a bug report about stability of PHP under multi-threaded environments and it's been blown-off as a "low-priority, known issue" by the people in charge.
I notice they don't explicitly call the first release "thread safe" but slyly lead you to believe so by explictly labeling the second "non-thread-safe" - that's a dirty trick to play.
It would seem that attaining true thread-safety is going to be critical for PHP's future. We've reached the point today where almost every computer sold has more than one processing core. It's a huge challenge. I've worked on multithreaded development projects since the early 1990s, mostly multithreading old Fortran algorithmic libraries. Today I'm community manager for the Threading Building Blocks open source project -- a C++ template library for multithreading applications.
Multithreading existing code is not easy, so I can certainly sympathize with the PHP developers. But, if your language is not threadsafe, you're going to fall away as a viable language as we proceed into the multicore future...
You might want to give Caucho's implementation of PHP called Quercus a try. It offers some great performance gains, and in combination with BEA's JRockit it might make a great alternative to the standard PHP interpreter.
http://www.caucho.com/
http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/jrockit/
Thanks for the links, Stephen.
We've looked at a number of alternative PHP processing engines, but haven't found a stable, reliable, and - most importantly - compatible implementation out there. (The bigger ones are RoadRunner and Phalanger; neither of which work well with the majority of the apps we tested).
Quercus sounds like a promising solution, I'm testing it now :)
Here is somebody for you to fight ;) http://doughboy.wordpress.com/2008/02/13/apache-worker-and-php/
and btw thanks for the caucho + jrockit tip, really interesting stuff!!!
Given this (ant not only) issue and many language defficiencies and problems I'm on my way to switch every simple to moderate project to .NET. If there is no acceptable production-safe PHP engine alternative, then you're better of leaving PHP and begin using some real language. It's a shame a language with almost no reasonable planning and designing behind it has become so widespread and we are stuck to it when it comes to some website that needs to run everywhere. Even worse, MS is planning a 'good' future for it on Windows. Maybe MS should take control and make it much better.
I finally got around to testing Quercus + Resin; unfortunately the combination's load times for individual PHP pages is around 110-120% of that for our currently (very finely-tuned) IIS + PHP + FastCGI implementation.
Perhaps Resin Professional, which stores the compiled PHP opcode instead of acting as a real-time interpreter, would provide a better performance output but the free solution isn't good enough. :-(