On 3/18/2011 9:24 AM, Rich Bowen wrote: > I wanted to be sure that folks are aware of what's going on in the > Windows/PHP world. I know that, in one sense, it's not our problem, but it > *feels* like our problem to me, and to many of our users.
Quite honestly, this leaves me with a taste to simply drop Windows builds altogether, and let the competing groups all prove up their own solutions. (including PHP, if they had the sense to ship an httpd build of their choice). This is little different than the competing binary builds for linux. There is an argument for, and available packages to install an entire lamp stack at once. They can do this because licensing the AL+MIT+GPL bits together is no issue to them. In reality, there's next to no reason to load PHP in process, I know of several engineers who have profiled the system load of in process mod_php vs. mod_fcgid with appropriately sized pools of php single processes with no threading. Very few deployments merit a 1:1 allocation of php workers to httpd workers, and this will become more striking as we move forward towards more asynch models. Of course a smaller number of single threaded php workers always wins, because PHP threading has reasonably high mutex contention, although I'm aware that the BDfL of php on win32 strongly disagrees with such results. But keep in mind, mod_perl and mod_python also suffer these issues, and they are interlocked into particular msvc runtimes that ActiveState, strawberry perl and others had elected. Even within their current shipping products, at any given time ActiveState perl and python are generally built with a different msvc flavor. Interesting for PHP to join the effort to further fragment the picture, today. (Yes, strawberry perl is an msys based build, but one that links in msvcr80). As I noted, switching now to VC9 when VC10 has been out for some time now is ass backwards. Within months [some 1 to 3 of them] there will be a finished 2.4.0 (which will be waiting for PHP binaries). If I go to the trouble of even offering some binaries, they certainly won't be using an already stale toolchain. The only sensible alternatives seem to be MSYS (and there too there is a question of which msvcrt version) or Mladen's proposal to stay with msvcrt, which I'm almost favoring right now.
