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. :-(
Hi, I think you have something very confused... 'mpm_worker on Apache, ISAPI on IIS, etc' are SAPI interfaces. Whether they are threadsafe or not is a matter of how they are coded. The PHP library itself is threadsafe.
This fact can be seen by looking at the source in php-5.2.x/sapi/cgi/fastcgi.c, as well as the rest of PHP's source tree. If you use PHP via fastcgi on windows, you are using a threaded PHP environment, its that simple.
However, ff you look at the source of php-5.2.x/sapi/isapi/php5isapi.c you will see that the SAPI does not use zends thread safty and is not threadsafe. This is a matter of the SAPI, not PHP itself.
The source for the files above can be viewed via googles code search
And for what its worth, Quercus is not a PHP implementation, it is PHP emulation. It is a set of Java wrappers to perform php functions. It can be called useful if it does the job that you need, but it is not PHP.
Even if the latest versions 5.3.0 or even older 5.2.10 are not thread-safe?
Otherwise, I firmly believe that PHP is not built for Microsoft world and even less for IIS and cloudy way to implement it with IIS anyway.
Apache under Windows could be better solution but could not be reliable enough, don't you think?
We're now running Apache for Windows on NeoSmart Technologies, and it's plenty reliable :)
I am quite new to PHP - but I do have a lot of experience with Java. Is the concern that there are no mutual exclusion constructs in PHP? Going through the PHP documentation it looks like there is support for mutual exclusion in PHP 4 and 5 - e.g., the semaphore and shared memory related functions.
While the language itself does not offer any synchronization or mutual exclusion mechanisms, the library of functions seem to be providing that - this is something similar to (say) C.
Am I missing something here?
I must admit, that one more time I feel ashamed for the answers I must read and for the time wasted - so to make it a turn I will write about what you made me think, just to justify the time lost. People are so unbelievably underdeveloped, this is real a problem. I totally do not understand why anybody has to argue about the question of PHP beeing Thread safe or not. It is OPEN SOURCE and you can take a look if it is or it is not. Its that simple! Do you argue about the question if a camel can fly? Another simple truth: if you are not able to find the answer yourself in the sourcecode - why are you concerned then anyway? If you are not competent to understand from the sources you can look at, what will it give you somebody telling you "it is threadsafe" or "it is not threadsafe"??? What exactly? A good feeling? Wouldn´t it be the same like somebody givin you a red balloon and telling you "boy, you can fly to the moon with this balloon"- and then making a blog post "i can not fly with the red balloon the guy out there gave me" - what would it feel like? But one thing is proven here: incompetent people always are like a magnet for their kind, yuo never get them alone... of course real "xperts" are coming here - guys that run a webserver on Windows - har har! Man, having concerns if your PHP is threadsafe under Windows is like a man wanting to cross the ocean with a camel and beeing concerned about the camel having good sunglasses. no sense. plain stupid. Go and THINK, LEARN or leave the brainwork to the people who did already before talking BS.
Please learn basic C++, then comment again, oh Visitor from the future. Unless you have a special gift that allows you to detect un-thread-safe code just like that.
Visitor from The Future, what's the point? You are pointless and worthless in affirmations.
Present visitor and user