I think the limitation of asynchronization is from the architecture of PHP running time enviroment. So the limitation is from PHP language itself. It does not support multithread. So how can it support asynchronization without extension?
Also, I see Java world has been improved its thread per request architecture for Servlet container. How will PHP catch up this?
Manuel Lemos - 2010-11-01 23:47:22 - In reply to message 1 from Yiyu Jia
There is not need for multi-threading support. Multi-threading is just a way to emulate asynchronous programming using the same calls you use for synchronous programming.
There is at least one PHP extension to create threads but that is not a reliable solution because other PHP extensions you need may not be thread safe. The PHP core code and Zend Engine are thread-safe though.
Yiyu Jia - 2010-11-02 21:51:01 - In reply to message 2 from Manuel Lemos
Thanks for your post. I learn a lot from your blog.
But, I think it depends on what kind application we will use PHP to develop. For example, how about using PHP to develop a Messaging Queue service like activeMQ? Of course, multithreading and asynchronous programming are two different concepts, which have certain relation.
Do you have some comments on Zend_Job? I am doing PHP programming for IBM i now. My main job is more related to back end service other than front end presentation. So, sometimes, I think it will be nice if PHP has built-in multithreading support.
As for Zend_Job and ActiveMQ, I think it most of the times you do not need a so called "high performance queue management system". It only makes your system more complicated and you often do not really have a demand to queue so many messages that justify it.
Most applications that need to have a queue just use a simple table on a regular database to which they insert records with details of the jobs to queue. Then another script just pops the pending job records from the database with another script that will execute the jobs as time permits.
The PHPClasses site uses a few tables as queues that work like that. It would be silly to use one of those so called "high performance queue systems" when in reality there is not such an high volume of job messages to be processed.
Other sites may have a much higher demand that would justify using a more robust queueing system though.