PHP has had a threading model for a very long time, since the first release of PHP4, May 22nd 2000.
Threading at the frontend
Creating user threads at the frontend of a web application doesn't make any sense; it is extremely difficult to scale. The thread per client model that the Apache Worker MPM binary and mod_php employ is not really something you want to use to serve your websites, certainly if you are using it, you do not want to create additional threads in direct response to any web requests.
Why are threads at the frontend a bad idea ?
You may often hear developers say threads at the frontend do not make sense, without providing the rationale for such an assertion. When you learn to think about systems in the required way the problem becomes obvious:
If a client script creates 8 threads in direct response to a web request, and 100 clients request the script simultaneously, you are requesting that your hardware execute 800 threads concurrently.
CPU's would have to look and work very very differently indeed to make that a good idea
What can we do about it ?
Enterprising solutions might well have a PHP website facing the public, but the actual brains of the system are written in languages that have good support for those things you require to build enterprising solutions such as Java, C#, C++ or whatever the language-of-the-day is.
You should use pthreads in the same way; by designing systems whose component parts are separated from one another, only connected by well designed, high performance (RPC) API's, such that the complexity inherent in designing a multi-threaded architecture is isolated completely from your public facing websites, and the simple, scalable setup that such a website will require.
U can now haz codes
Let's start at the beginning with Hello World:
<?php
class My extends Thread {
public function run() {
printf("Hello World\n");
}
}
/* create a new Thread */
$my = new My();
/* start the Thread */
$my->start();
/* do not allow PHP to manage the shutdown of your Threads */
/* if a variable goes out of scope in PHP it is destroyed */
/* joining explicitly ensures integrity of the data contained in an objects */
/* members while other contexts may be accessing them */
$my->join();
?>
Boring, but I hope you read it ;)
So in a real system, you don't really want to be creating threads so explicitly, you surely want to just submit tasks to some executor service, all of the complex systems, in the sense of their multi-tasking requirements, I have ever seen use such things ...
<?php
class My extends Threaded {
public function run() {
printf("Hello World from %s#%lu\n",
__CLASS__, Thread::getCurrentThreadId());
}
}
/* create a Pool of four threads */
/* threads in a pool are created when required */
$pool = new Pool(4);
/* submit a few tasks to the pool */
$tasks = 100;
while ($tasks--) {
$pool->submit(new My());
}
/* shutting down the pool is tantamount to joining all workers */
/* remember what I said about joining ? */
$pool->shutdown();
?>
I have given you very brief explanations of complicated things, you should endeavor to read all you can:
Many examples can be found here: https://github.com/krakjoe/pthreads/tree/master/examples
Disclaimer: There's nothing really wrong with a server architecture that uses threading, but the moment you start to create additional threads, you restrict it's scalability and ability to perform as it was designed, I can imagine well designed architectures that do have the ability to thread at the frontend, but it is not an easy thing to aim for. Additionally, threading is not the only thing in the toolbox when it comes to high performance web targeted applications; research all your options.
