From: larry at garfieldtech dot com > On 3/23/10 6:04 PM, Tommy Pham wrote:
>> If throwing hardware at it won't work because of the above mentioned, >> then you would change the design right? How long would that take? >> What if PHP has threads, how long would it take you implement threads >> with minor changes versus and overhaul of application design, coding, >> QA, etc... In summary, you're saying that PHP can not grow/evolve with >> business right? If the company started small and want to use >> available open source solutions, then grow quickly because of their >> unique and quality products and services, and become enterprise level >> with-in a few years, what then? Slow down business growth just so >> that IT can migrate everything to another language? Of all the >> enterprise applications I've seen, they used threads. > > But let's consider what adding threads to PHP would take. That would > mean making PHP a shared-memory architecture, so that different requests > now operated in the same memory space. That means RAM-based > persistence. That means needing to write thread-safe PHP libraries. > (Not the ones in C; I mean the millions of lines of code of PHP already > out there.) > > In short, adding threading support to PHP means PHP is no longer PHP. > It's Java with dollarsigns. It's a complete and total rewrite of the > entire language runtime and environment, and all of the code build atop it. > > The idea that you could "just add threads" to PHP and make it > "enterprise-ready" is so naive it's mind boggling. This pretty much describes the path the Perl community took several years back. While they didn't end up looking like Java, they still actively discourage the use of threads in Perl because nobody has a good handle on which portions of CPAN are actually thread safe. It will likely take them several more years before they find and fix all of the libraries and modules that aren't. Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
