Re: php and multithreading (additional arguments)
| From: | speedy | 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