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.s...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
