Re: php and multithreading (additional arguments)

From: Date: Thu, 01 Apr 2010 16:03:11 +0000
Subject: Re: php and multithreading (additional arguments)
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-47703@lists.php.net to get a copy of this message
Hello Rasmus, Thursday, April 1, 2010, 5:21:55 PM, you wrote: > On 04/01/2010 07:32 AM, speedy wrote: >> 1. Imagine that from time to time, some background processing takes 1 >> second of CPU time - w/o multithreading, all your async operations, >> like accepting a connection to a socket, aio or others are basically >> stalled. So, async is a good approach, but does not work as a magic >> wand for all problem spaces. Alternatively, you could fork and then do the >> processing, but then the state syncing of the forked background processing >> results with the main thread requires a whole new protocol / switching to >> interprocess communication, which makes such developments unnecessarily >> hard. Threads exist for a _reason_ not only because they sound cool. > There are plenty of mechanisms/protocols for doing this. Gearman works > extremely well for managing out-of-band jobs like this, for example. Yes, but sometimes, esp. in more real-time oriented applications, state merging is very hard to do - though I agree that protocols and mechanisms exist for out of band processing, there are plenty of cases in which they are suboptimal. >> 2. Without thread support, it is not possible to use multi-core processing >> paradigms directly from PHP - which means PHP relies on external frameworks for >> that feature, which, in a sense, makes it a non-general-purpose language. >> It _could become_ a general purpouse tool, if it had proper multi-threading >> support built-in. > PHP is not a general-purpose language and there are no plans to make it > one. Your OS provides scheduling and is responsible for making best use > of your multiple cores. With many concurrent web requests your multiple > cores should be put to good use. Current situational facts are against that claim - with PHP delivered as a CLI interpreter, and via that route, having more and more software applications written outside the web serving scope/domain, PHP has spontaneously made strides into becoming a general purpouse tool. I think the only remaining step in that direction is to have the native multi-threading support. I plan to check out how hard would that be, and see how many people would be needed for developing that feature in some reasonable time-frame. Also, keep in mind that the web is slowly shifting towards real-time communication / streaming with emergence of Comet, HTML5 Web Sockets etc. There are already many web server implementations specialising in that, and PHP is _not_ their language of choice. > -Rasmus -- Best regards, speedy mailto:speedy.spam@gmail.com

« previous php.internals (#47703) next »