On Wed, Oct 31, 2012 at 6:46 AM, Alex Nikitin <niksoft@xxxxxxxxx> wrote: > Hey guys (and/or gals), > > I have heard this question entirely too many times, I think at some point > Rasmus just stopped responding to it. The real reason that PHP is not > threaded has nothing to do with PHP internal or extension thread safety, > the reason is more to the extent that it doesn't make sense to add > threading to PHP, it will only increase code and model complexity and > create more points of failure, but again the reason is not this, the reason > is that it doesn't make sense in PHP's native environment to add threading > in the first place. Natively PHP is summoned by a web server, yes you can > call PHP in CLI, but that's not it's point market, PHP is first and > foremost a server-side language for the web and it is ran by a web server > such as Apache or Nginx or IIS(i wouldn't know why you would use IIS, but > it could be). All of these web servers (maybe with exception of IIS, i > wouldn't know) work pretty much on the same principal, you have the main > process that spawns a bunch of worker threads (this is adjustable in > configuration, but is typically 1 per cpu thread). These threads are what > actually process the requests and call PHP, meaning that if multiple > threads are processing multiple requests, multiple instances of PHP will be > called. This is why adding threading to PHP makes absolutely no sense, why > would you spawn threads in something that is already being called by a > thread? Don't get me wrong, threads spawning other threads is a solution, > but it is a solution on massively parallel architectures, such as the > GPGPUs that can handle over a thousand threads, and it is a solution for an > entirely different problem, namely costly conditional statements; PHP on > the other hand runs on a general purpose processor that already cache > thrashes and runs into issues with instruction pipelines in parallel > execution, adding more threads to it would do nothing for performance (or > make it worse), make for more complex code and introduce new issues, like > for example how do you test threaded code, debugging, messaging, etc, which > will introduce new places where php apps fail, new security concerns, etc, > and I think we are far from having current issues fixed... That's all understood but there are times when that one request from the visitor requires many sub-requests like connection to DB and making SOAP calls. Sure, it can much faster do you think the response time for the visitor when the sub requests are done in child threads? Sure, I could implement curl_multi as you state below. > > Want to parallelize your PHP execution? Learn to love curl_multi :) > > In this case, fix the program, not the programming language. Just my $0.02 > But how do you then manage those calls or sub-threads? What about synchronizing? Like you said, fix the program right? Then shouldn't that be fixed in PHP at the core rather than a hack after? Cheers, Tommy > > -- Alex > -- > The trouble with programmers is that you can never tell what a programmer > is doing until it’s too late. ~Seymour Cray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
