Does PHP have threading?

Question

I found this PECL package called threads, but there is not a release yet. And nothing is coming up on the PHP website.

Palpitant

Anyone know if this (pcntl_fork()) will work if called from Apache? – Governor

This is incredibly old, but I have an answer that actually provides threading in php (see below for links). – Rashida

They recommend not calling fork from a server environment. I don't blame them. However, pcntl_fork does seem to be the best solutions for threading PHP. – Cortisone

Yes you shouldn't need to fork an apache2 php process. – Legalese

Use pthreads works like charm – Broads

Check: https://mcmap.net/q/76063/-threads-in-php – Boz

Answer 1

There is nothing available that I'm aware of. The next best thing would be to simply have one script execute another via CLI, but that's a bit rudimentary. Depending on what you are trying to do and how complex it is, this may or may not be an option.

Diplomatic

That's what I thought. I saw a bunch of older postings saying no, and nothing on php.net, so this was my thought. Thanks for confirming it. – Palpitant

Yeah, that PECL package is kind of a tease - I ran across it as well but nothing has ever come of it. – Diplomatic

Answer 2

From the PHP manual for the pthreads extension:

pthreads is an Object Orientated API that allows user-land multi-threading in PHP. It includes all the tools you need to create multi-threaded applications targeted at the Web or the Console. PHP applications can create, read, write, execute and synchronize with Threads, Workers and Stackables.

As unbelievable as this sounds, it's entirely true. Today, PHP can multi-thread for those wishing to try it.

The first release of PHP4, 22 May 2000, PHP was shipped with a thread safe architecture - a way for it to execute multiple instances of it's interpreter in separate threads in multi-threaded SAPI ( Server API ) environments. Over the last 13 years, the design of this architecture has been maintained and advanced: It has been in production use on the worlds largest websites ever since.

Threading in user land was never a concern for the PHP team, and it remains as such today. You should understand that in the world where PHP does it's business, there's already a defined method of scaling - add hardware. Over the many years PHP has existed, hardware has got cheaper and cheaper and so this became less and less of a concern for the PHP team. While it was getting cheaper, it also got much more powerful; today, our mobile phones and tablets have dual and quad core architectures and plenty of RAM to go with it, our desktops and servers commonly have 8 or 16 cores, 16 and 32 gigabytes of RAM, though we may not always be able to have two within budget and having two desktops is rarely useful for most of us.

Additionally, PHP was written for the non-programmer, it is many hobbyists native tongue. The reason PHP is so easily adopted is because it is an easy language to learn and write. The reason PHP is so reliable today is because of the vast amount of work that goes into it's design, and every single decision made by the PHP group. It's reliability and sheer greatness keep it in the spot light, after all these years; where it's rivals have fallen to time or pressure.

Multi-threaded programming is not easy for most, even with the most coherent and reliable API, there are different things to think about, and many misconceptions. The PHP group do not wish for user land multi-threading to be a core feature, it has never been given serious attention - and rightly so. PHP should not be complex, for everyone.

All things considered, there are still benefits to be had from allowing PHP to utilize it's production ready and tested features to allow a means of making the most out of what we have, when adding more isn't always an option, and for a lot of tasks is never really needed.

pthreads achieves, for those wishing to explore it, an API that does allow a user to multi-thread PHP applications. It's API is very much a work in progress, and designated a beta level of stability and completeness.

It is common knowledge that some of the libraries PHP uses are not thread safe, it should be clear to the programmer that pthreads cannot change this, and does not attempt to try. However, any library that is thread safe is useable, as in any other thread safe setup of the interpreter.

pthreads utilizes Posix Threads ( even in Windows ), what the programmer creates are real threads of execution, but for those threads to be useful, they must be aware of PHP - able to execute user code, share variables and allow a useful means of communication ( synchronization ). So every thread is created with an instance of the interpreter, but by design, it's interpreter is isolated from all other instances of the interpreter - just like multi-threaded Server API environments. pthreads attempts to bridge the gap in a sane and safe way. Many of the concerns of the programmer of threads in C just aren't there for the programmer of pthreads, by design, pthreads is copy on read and copy on write ( RAM is cheap ), so no two instances ever manipulate the same physical data, but they can both affect data in another thread. The fact that PHP may use thread unsafe features in it's core programming is entirely irrelevant, user threads, and it's operations are completely safe.

Why copy on read and copy on write:

public function run() {
    ...
    (1) $this->data = $data;
    ...
    (2) $this->other = someOperation($this->data);
    ...
}

(3) echo preg_match($pattern, $replace, $thread->data);

(1) While a read, and write lock are held on the pthreads object data store, data is copied from its original location in memory to the object store. pthreads does not adjust the refcount of the variable, Zend is able to free the original data if there are no further references to it.

(2) The argument to someOperation references the object store, the original data stored, which it itself a copy of the result of (1), is copied again for the engine into a zval container, while this occurs a read lock is held on the object store, the lock is released and the engine can execute the function. When the zval is created, it has a refcount of 0, enabling the engine to free the copy on completion of the operation, because no other references to it exist.

(3) The last argument to preg_match references the data store, a read lock is obtained, the data set in (1) is copied to a zval, again with a refcount of 0. The lock is released, The call to preg_match operates on a copy of data, that is itself a copy of the original data.

Things to know:

• The object store's hash table where data is stored, thread safe, is
  based on the TsHashTable shipped with PHP, by Zend.

• The object store has a read and write lock, an additional access lock is provided for the TsHashTable such that if requires ( and it does, var_dump/print_r, direct access to properties as the PHP engine wants to reference them ) pthreads can manipulate the TsHashTable outside of the defined API.

• The locks are only held while the copying operations occur, when the copies have been made the locks are released, in a sensible order.

This means:

• When a write occurs, not only are a read and write lock held, but an additional access lock. The table itself is locked down, there is no possible way another context can lock, read, write or affect it.

• When a read occurs, not only is the read lock held, but the additional access lock too, again the table is locked down.

No two contexts can physically nor concurrently access the same data from the object store, but writes made in any context with a reference will affect the data read in any context with a reference.

This is shared nothing architecture and the only way to exist is co-exist. Those a bit savvy will see that, there's a lot of copying going on here, and they will wonder if that is a good thing. Quite a lot of copying goes on within a dynamic runtime, that's the dynamics of a dynamic language. pthreads is implemented at the level of the object, because good control can be gained over one object, but methods - the code the programmer executes - have another context, free of locking and copies - the local method scope. The object scope in the case of a pthreads object should be treated as a way to share data among contexts, that is it's purpose. With this in mind you can adopt techniques to avoid locking the object store unless it's necessary, such as passing local scope variables to other methods in a threaded object rather than having them copy from the object store upon execution.

Most of the libraries and extensions available for PHP are thin wrappers around 3rd parties, PHP core functionality to a degree is the same thing. pthreads is not a thin wrapper around Posix Threads; it is a threading API based on Posix Threads. There is no point in implementing Threads in PHP that it's users do not understand or cannot use. There's no reason that a person with no knowledge of what a mutex is or does should not be able to take advantage of all that they have, both in terms of skill, and resources. An object functions like an object, but wherever two contexts would otherwise collide, pthreads provides stability and safety.

Anyone who has worked in java will see the similarities between a pthreads object and threading in java, those same people will have no doubt seen an error called ConcurrentModificationException - as it sounds an error raised by the java runtime if two threads write the same physical data concurrently. I understand why it exists, but it baffles me that with resources as cheap as they are, coupled with the fact the runtime is able to detect the concurrency at the exact and only time that safety could be achieved for the user, that it chooses to throw a possibly fatal error at runtime rather than manage the execution and access to the data.

No such stupid errors will be emitted by pthreads, the API is written to make threading as stable, and compatible as is possible, I believe.

Multi-threading isn't like using a new database, close attention should be paid to every word in the manual and examples shipped with pthreads.

Lastly, from the PHP manual:

pthreads was, and is, an experiment with pretty good results. Any of its limitations or features may change at any time; that is the nature of experimentation. It's limitations - often imposed by the implementation - exist for good reason; the aim of pthreads is to provide a useable solution to multi-tasking in PHP at any level. In the environment which pthreads executes, some restrictions and limitations are necessary in order to provide a stable environment.

Memorial

Can you please clarify this: "...so no two instances ever manipulate the same physical data, but they can both affect data in another thread..." In my understanding if one thread may affect data in another, this other thread has to take care about synchronization. If it doesn't (non-thread-safe library), you are doomed - regardless whether you use copy-on-write or do it directly. What don't i get here? – Gruver

So I could answer properly, I have updated the original question. – Memorial

ok, i tried to test what you described about copying and so on, but my tests failed, because of an issue, i created a separate question for: https://mcmap.net/q/76064/-pthread-thread-objects-reset-their-state/1703313 – Gruver

thank you, Joe. Pthreads is awesome, a nice addition to PHP developer community. – Azeotrope

I do not agree with most of the arguments regarding the design intentions. Any programming language tryes to keep the things as simple and as readable as possible. The thing with PHP is that it's at a higher level than other languages. It was made for web, so it evolved like so (http processor). Because it's at a high level, and designed for web it's "easyer" to understand. It's focused on web. You can learn java at the same pase as PHP if you use it for web (use the same language features that php provides) . -1 – Cartography

@GeoC. I'm not even sure what your point is here, that's just a load of gibberish and you provide no reasons, logical or otherwise, as to why you do not agree with any arguments (of which I cannot really see any in the post). – Garlinda

@JoeWatkins I must agree with Geo, your arguments are invalid. "php was meant for the non programmer" :) . Php has eveolved in a different way, it was designed solely for the web, it is not a general purpose programming language. No wonder it is the most weidly used web programming language (with big "players"). Now days you should think at a very high level mostly (if you want low go with c or assembley for mapping). You should scale each decision you take for implementation. Threads are even useless when it comes to async processing for the web. – Diaconal

@JoeWatkins Also regarding how fast can you go up and write java web apps, there are plenty of frameworks out there that makes your life plain simple. An experienced oo php developer can jump fast into java any time. If you have solved scalable async problems with php (for web ofcourse) you'll definetly do it with java (php borrowed alot from java). – Diaconal

@Garlinda Big answer, just words in the wind :), that's the problem . Allthough threads would help in some cases, php is not a general purpose programming language, it was built for the web, in which case the whole async processing shifts into more complex soluttion than handling paralel (not synced) operations on the same machine. Joe tryed to emphasize the fact that php is not a programming language and that's why it does not support multi threading. Little does he know that multi threading is not a big win in the case of web architecture. – Diaconal

@Diaconal I don't think you really know what you are talking about, so I'm happy to ignore you. – Memorial

@JoeWatkins I'm talking about soa, messaging between components as a means of parallel programming. How you deal with the memory space of each component is just a detail (thread, process, cluster node, web server). – Diaconal

@n.b. :) Threads are the means for async programming, that's the basic meaning of them. If you would ever have to do with hrizontal scalability and event driven design along with event sourcing, you would really understand what i'm saying. You would rarely need to use paralel programming on the machine side. When you use take use of infrastructure enterprize software like rabbitmq or nservicebus or akka you don't actually need threads anymore. The messaging bus can do the rest. – Diaconal

@Diaconal - I work with ZeroMQ and SOA, pthreads fall into place perfectly. The nonsense you're spouting is simply fanboyism and being oblivious to, well, programming in general. As a business owner, it's much more efficient to keep using PHP programmers rather than swapping stacks to Scala or Java, a fact that any sane person knows well. The existence of threads in userland enables a wider use of PHP and contrary to some popular belief you're presenting here - PHP is a general purpose programming language. It's only up to you whether you accept that fact or keep believing in ghosts. – Picayune

@JoeWatkins I guess it's hard for you to understand that the web is going in another direction than the simple one machine do it all. If you are really doing web applications that are ment do be handled by one machine i realy don't get the point of using another lower level language than PHP . Any argument you provide does not sustain that PHP is not proper for web. The only disatvange is that it's interpreted. But that does not make it a weak language , neither the absesnce of threads like i explained above. Your arguments are invalid . – Diaconal

@Picayune My arguments are pro PHP . I don't understand why would you swap stacks? When I'm talking about messaging infrastructure my main use is for publishing events and notifications in a DDD manner. You actually do not need threads, just events and listeners for paralel programming. There are no stacks, just autonomus components , you can't view soa as a stack, same goes to DDD . If you really need threads for some fine grained tasks, you can allways get/build a thread extension. My point was that the way PHP is designed is for other things : mainly web. – Diaconal

@Diaconal - PHP evolved a long time ago from the original purpose (as many languages have) - which was simple, we all know the story. There is absolutely nothing wrong with being able to use threads from userland compared to writing an extension to do so. Yes, there are perfect use scenarios where pthreads fit in perfectly. You don't always have to use PHP together with a web server after all. The only "bad" thing with pthreads is that the PHP developers haven't evolved enough to be able to utilise it to its potential. – Picayune

@Picayune This type of design, architecture has nothing to do with the technology used. You can use php or java or anything you want. Building something that works based on async commands (each command is an autonomus operation that triggers an event for later processing) has nothing to do with the underlone technology. This is the async type of programming suited for modern web applications. Threads are suited more for apps that are deployed and work on one tire like windows apps . – Diaconal

You do not need to start another thread to send an email, change another part inside a SOA component. Just design an autonomus transactional command, trgger an event after it has finished let the messaging infrastructure do the rest. That's why threads are not strictly required for web apps , and that's why i think php evolved in this manner , without including them in it's core functionality. Again PHP main purpose is for web (but yes you can do many more with it). – Diaconal

@JoeWatkins, State your allegiance. – Fathead

Funny thing. Joe Watkins is the author of pthreads, and still Tudor tries to prove him wrong. – Lorenzetti

Thank you very much for this great answer and for making php pthreads. There is a big red warning in the manual that says "pthreads (v3) can only be used with PHP 7.2+: This is due to ZTS mode being unsafe in 7.0 and 7.1. " does this mean that using pthreads with php <7.0 is unsafe ? – Moo

Answer 3

Here is an example of what Wilco suggested:

$cmd = 'nohup nice -n 10 /usr/bin/php -c /path/to/php.ini -f /path/to/php/file.php action=generate var1_id=23 var2_id=35 gen_id=535 > /path/to/log/file.log & echo $!';
$pid = shell_exec($cmd);

Basically this executes the PHP script at the command line, but immediately returns the PID and then runs in the background. (The echo $! ensures nothing else is returned other than the PID.) This allows your PHP script to continue or quit if you want. When I have used this, I have redirected the user to another page, where every 5 to 60 seconds an AJAX call is made to check if the report is still running. (I have a table to store the gen_id and the user it's related to.) The check script runs the following:

exec('ps ' . $pid , $processState);
if (count($processState) < 2) {
     // less than 2 rows in the ps, therefore report is complete
}

There is a short post on this technique here: http://nsaunders.wordpress.com/2007/01/12/running-a-background-process-in-php/

Joettejoey

i have a slight problem, how do u check the status of the background process? can u enlighten me – Cytoplasm

Answer 4

In short: yes, there is multithreading in php but you should use multiprocessing instead.

Backgroud info: threads vs. processes

There is always a bit confusion about the distinction of threads and processes, so i'll shortly describe both:

• A thread is a sequence of commands that the CPU will process. The only data it consists of is a program counter. Each CPU core will only process one thread at a time but can switch between the execution of different ones via scheduling.
• A process is a set of shared resources. That means it consists of a part of memory, variables, object instances, file handles, mutexes, database connections and so on. Each process also contains one or more threads. All threads of the same process share its resources, so you may use a variable in one thread that you created in another. If those threads are parts of two different processes, then they cannot access each others resources directly. In this case you need inter-process communication through e.g. pipes, files, sockets...

Multiprocessing

You can achieve parallel computing by creating new processes (that also contain a new thread) with php. If your threads do not need much communication or synchronization, this is your choice, since the processes are isolated and cannot interfere with each other's work. Even if one crashes, that doesn't concern the others. If you do need much communication, you should read on at "multithreading" or - sadly - consider using another programming language, because inter-process communication and synchronization introduces a lot of complexion.

In php you have two ways to create a new process:

let the OS do it for you: you can tell your operation system to create a new process and run a new (or the same) php script in it.

• for linux you can use the following or consider Darryl Hein's answer:

  $cmd = 'nice php script.php 2>&1 & echo $!';
  pclose(popen($cmd, 'r'));
  

• for windows you may use this:

  $cmd = 'start "processname" /MIN /belownormal cmd /c "script.php 2>&1"';
  pclose(popen($cmd, 'r'));
  

do it yourself with a fork: php also provides the possibility to use forking through the function pcntl_fork(). A good tutorial on how to do this can be found here but i strongly recommend not to use it, since fork is a crime against humanity and especially against oop.

Multithreading

With multithreading all your threads share their resources so you can easily communicate between and synchronize them without a lot of overhead. On the other side you have to know what you are doing, since race conditions and deadlocks are easy to produce but very difficult to debug.

Standard php does not provide any multithreading but there is an (experimental) extension that actually does - pthreads. Its api documentation even made it into php.net. With it you can do some stuff as you can in real programming languages :-) like this:

class MyThread extends Thread {
    public function run(){
        //do something time consuming
    }
}

$t = new MyThread();
if($t->start()){
    while($t->isRunning()){
        echo ".";
        usleep(100);
    }
    $t->join();
}

For linux there is an installation guide right here at stackoverflow's.

For windows there is one now:

• First you need the thread-safe version of php.
• You need the pre-compiled versions of both pthreads and its php extension. They can be downloaded here. Make sure that you download the version that is compatible with your php version.
• Copy php_pthreads.dll (from the zip you just downloaded) into your php extension folder ([phpDirectory]/ext).
• Copy pthreadVC2.dll into [phpDirectory] (the root folder - not the extension folder).

• Edit [phpDirectory]/php.ini and insert the following line

  extension=php_pthreads.dll
  

• Test it with the script above with some sleep or something right there where the comment is.

And now the big BUT: Although this really works, php wasn't originally made for multithreading. There exists a thread-safe version of php and as of v5.4 it seems to be nearly bug-free but using php in a multi-threaded environment is still discouraged in the php manual (but maybe they just did not update their manual on this, yet). A much bigger problem might be that a lot of common extensions are not thread-safe. So you might get threads with this php extension but the functions you're depending on are still not thread-safe so you will probably encounter race conditions, deadlocks and so on in code you did not write yourself...

Gruver

That's horribly wrong, the article you referenced is from 2008. If PHP weren't thread safe at the core it wouldn't have threaded SAPI modules. – Memorial

@Joe: Allright, i changed it in core is thread-safe but lots of extensions aren't. – Gruver

Lots ? I think you'll find it's very few, you've found the documentation but failed to read it properly: Note: Those marked with * are not thread-safe libraries, and should not be used with PHP as a server module in the multi-threaded Windows web servers (IIS, Netscape). This does not matter in Unix environments, yet. – Memorial

PHP is very thread safe, and has been for many years, some of the external libraries and a couple of bundled ones are not, but it's well documented, and pretty obvious anyway. pthreads creates threads that are as safe as the threads created by zend in a multi-threaded sapi, I know this, because I, alone, wrote pthreads. It uses every available API exposed by PHP just as the server API's do, I'm not saying it's completely stable, but the picture you have painted is just plain wrong and very poorly informed. – Memorial

@Joe: When the manual says this does not matter for Unix environments they are referring to the fact that on Unix system apache uses multiple processes and on Windows it uses threads. So basically they are saying "if you aren't using threads anyway, you don't have to worry about non-thread-safe extensions." When we use threads with pthreads, it - of course - does matter on Unix environments, too. – Gruver

@Joe: btw, thank you for building pthreads. Don't get me wrong, i'm very glad that pthreads exists. I'm criticising php here - not pthreads. – Gruver

Answer 5

You can use pcntl_fork() to achieve something similar to threads. Technically it's separate processes, so the communication between the two is not as simple with threads, and I believe it will not work if PHP is called by apache.

Cool

I'm successfully using pcntl_fork to parallelize a pretty massive data import task. Works great, and I had it working in about an hour. There's a bit of a learning curve, but once you understand what's going on, it's pretty straight forward. – Brunner

Frank, is that with CLI php or apache PHP? – Choate

@Artem: I'd like to know too. – Governor

@Frank Farmer is teasing us... just like PECL package. – Nitrobacteria

I was using pcntl_fork with CLI. I've never tried it in apache; that sounds risky. Even on CLI, there were some unexpected issues. I seemed to be having a problem where if one child closed a database handle (because it finished its work), it closed the connection for siblings as well. Since children are copies of the parent, prepare for oddity. I've since redesigned my code to simply spawn new, completely separate processes via exec() -- it's cleaner that way. – Brunner

I have an application where I've made an entry point for both Apache and CLI. The application uses pcntl_fork() heavily, and I've noticed so ill effects from using Apache instead of CLI – Hysterectomy

Answer 6

If anyone cares, I have revived php_threading (not the same as threads, but similar) and I actually have it to the point where it works (somewhat) well!

Project page

Download (for Windows PHP 5.3 VC9 TS)

Examples

README

Rashida

Answer 7

pcntl_fork() is what you are searching for, but its process forking not threading. so you will have the problem of data exchange. to solve them you can use phps semaphore functions ( http://www.php.net/manual/de/ref.sem.php ) message queues may be a bit easier for the beginning than shared memory segments.

Anyways, a strategy i am using in a web framework that i am developing which loads resource intensive blocks of a web page (probably with external requests) parallel: i am doing a job queue to know what data i am waiting for and then i fork off the jobs for every process. once done they store their data in the apc cache under a unique key the parent process can access. once every data is there it continues. i am using simple usleep() to wait because inter process communication is not possible in apache (children will loose the connection to their parents and become zombies...). so this brings me to the last thing: its important to self kill every child! there are as well classes that fork processes but keep data, i didn't examine them but zend framework has one, and they usually do slow but reliably code. you can find it here: http://zendframework.com/manual/1.9/en/zendx.console.process.unix.overview.html i think they use shm segments! well last but not least there is an error on this zend website, minor mistake in the example.

while ($process1->isRunning() && $process2->isRunning()) {
    sleep(1);
}
should of course be:
while ($process1->isRunning() || $process2->isRunning()) {
    sleep(1);
}

Desiccated

Answer 8

There is a Threading extension being activley developed based on PThreads that looks very promising at https://github.com/krakjoe/pthreads

Xanthin

Answer 9

Just an update, its seem that PHP guys are working on supporting thread and its available now.

Here is the link to it: http://php.net/manual/en/book.pthreads.php

Cruet

Answer 10

I have a PHP threading class that's been running flawlessly in a production environment for over two years now.

EDIT: This is now available as a composer library and as part of my MVC framework, Hazaar MVC.

See: https://git.hazaarlabs.com/hazaar/hazaar-thread

Indiscrimination

What if, following your example, the program in file.php, lets say for example, it veryfies the existence of a list of 10k website's uris and then has to save the result in a CSV file... Would this file writting be a problem? – Nitrobacteria

The sub process will run as the same user as the web-server/parent script. So When writing files you will have the the same considerations regarding permissions as you normally would. If you have problems writing files, try writing to /tmp and when that's working, go from there. – Indiscrimination

The link is now dead due to a redesign, you can get it on the wayback machine here : web.archive.org/web/20130922043615/http://dev.funkynerd.com/… – Millner

Added to my MVC framework now. See: git.hazaarlabs.com/hazaar/hazaar-thread – Indiscrimination

Answer 11

I know this is a way old question, but you could look at http://phpthreadlib.sourceforge.net/

Bi-directional communication, support for Win32, and no extensions required.

Boykin

Answer 12

Ever heard about appserver from techdivision?

It is written in php and works as a appserver managing multithreads for high traffic php applications. Is still in beta but very promesing.

Pammy

Answer 13

There is the rather obscure, and soon to be deprecated, feature called ticks. The only thing I have ever used it for, is to allow a script to capture SIGKILL (Ctrl+C) and close down gracefully.

Shull

Ticks do not execute in parallel. Essentially, after every statement, your tick function runs. While your tick function is running, the main code is not running. – Brunner

ticks are only needed for signal() handler. – Incautious