Joe Watkins has a post to his site talking about polyfills and pthreads and some feedback he received during his work on the extension that allows for multi-threaded handling in PHP.

Recently a fellow githubber opened an issue for pthreads, they are writing a static analysis suite for PHP, and are attempting to integrate pthreads into their code. First thing to say is, I don't know where that will lead him. But it does give him the problem that a lot of environments don't have pthreads available, and or they aren't using a thread safe interpreter.

In the issue, he made the suggestion that we have a compatibility layer, a polyfill. I confess, this had never occurred to me before. Not only does it solve his problem but it actually serves as a useful tool ... I shall explain.

He starts by answering a question he's gotten a lot during his work on pthreads: "what's a good use case for threading?" Instead he answers a question that follows the intent a bit more: "What kind of code lends itself to threading?" He talks about units of work and separation of responsibility and how it "avoids synchronization" that could be caused by unforeseen circumstances. He instead recommends that, for most applications, true multi-threading probably isn't needed and a polyfill that simulates the functionality is probably good enough.

On Reddit.com there's a post from krakjoe talking about using multithreating in PHP, specifically with pthreads. Unfortunately, there's several misconceptions about the pthreads (and concurrency) that still makes it difficult in PHP. The post lists a few of them:

• PHP is not thread safe, there are lots of extensions that will give your application cooties.
• pthreads is old fashioned
• pthreads does not include everything you need to execute safely
• pthreads unsafely shares memory among contexts in order to provide concurrent functionality
• pthreads is beta and should be avoided at all costs

The author points out that pthreads are still in more of a "beta" state and probably shouldn't be used in production (though some do):

Multi-threading in PHP sounds like some sort of voodoo, for so long it's been something that was either impossible in the minds of php programmers, or a bad idea to try and emulate. pthreads doesn't emulate anything, it leverages bundled functionality and the object API to provide true userland multi-threading.

In doing some work with Zero (PHP in Java) and the Eclipse Business Intelligence and Reporting Tools project, Ant Phillips had some troubles with multithreaded PHP processes and wanting them all to use the same BIRT instance insted of spawning their own.

The problem is that BIRT needs to be started once, and only once, in any given process. Once it has been started up, then it is plain sailing to load reports and render them to HTML. The BIRT runtime should be kept around until the process shuts down.

Two problems came up with this approach - if each PHP process makes its own BIRT process any settings/current data will be wiped out and the BIRT instance would go away whenever the PHP script finishes. He found something that solves both of these problems - the Zero Global Context. Its a "storage area" that can contain just about anything. He used it to store the BIRT runtime until its told to finish and die off.

As mentioned on the Zend Developer Zone, there's a new tutorial posted on the IBuildings blog (by Lineke Kerckhoffs-Willems) about performing some multi-threading magic in PHP with the help of cURL.

Each PHP request is a separate thread. There are some workarounds like using pcntl_fork, starting multiple commandline php processes using the exec command or even using ajax. Another possibility is using the Curl library. Besides the basic functions described above Curl offers the "multi" functions for retrieving content from several url's at the same time.

Examples are included showing how to make these "multi" requests via PHP's cURL support (calling URLs with a "seconds" value on the end).

In this new post to the PHP 10.0 blog, Stas mentions the "impending doom" of PHP that's been going around the community, including in this post on the TechRepublic site.

He does, however, branch off into something much more interesting that seems to be somewhat ignored by developers - the use of ticks on their code:

This is something named "ticks" - I wonder how many of the PHP developers heard about it and of those how many actually used it. Could it be used for offloading long-running I/O-bound tasks or grouping them together (e.g. so we could wait for DB and HTTP in parallel and not sequentially)? Would there be any use at all for such functionality and if so - how it's supposed to work? I.e. how would you know it's done and how you would collect and use the results?

It's suggested in the comments that it could be used for any kind of application that might need the pseudo-multithreading it offers (including something like scripts needing multiple TCP connections).

In this new post to the PHP 10.0 blog, Stas mentions the "impending doom" of PHP that's been going around the community, including in this post on the TechRepublic site.

He does, however, branch off into something much more interesting that seems to be somewhat ignored by developers - the use of ticks on their code:

This is something named "ticks" - I wonder how many of the PHP developers heard about it and of those how many actually used it. Could it be used for offloading long-running I/O-bound tasks or grouping them together (e.g. so we could wait for DB and HTTP in parallel and not sequentially)? Would there be any use at all for such functionality and if so - how it's supposed to work? I.e. how would you know it's done and how you would collect and use the results?

It's suggested in the comments that it could be used for any kind of application that might need the pseudo-multithreading it offers (including something like scripts needing multiple TCP connections).

In two previous posts, the AlternateInterior blog looked at working with threading in PHP. They continue along this path with this new post today - benchmarking some of their threading techniques.

All threads can now both hear and report on conditions. A problem with the original send/receive mechanism made threads hang the controlling thread while long operations were occurring.

After updating some of their HVAC class to make it a little easier to understand/use, they ran some benchmarks on running processes two different ways - multithreaded and sequential.

The package is available for download if you'd like to work with it/run the tests yourself.

In two previous posts, the AlternateInterior blog looked at working with threading in PHP. They continue along this path with this new post today - benchmarking some of their threading techniques.

All threads can now both hear and report on conditions. A problem with the original send/receive mechanism made threads hang the controlling thread while long operations were occurring.

After updating some of their HVAC class to make it a little easier to understand/use, they ran some benchmarks on running processes two different ways - multithreaded and sequential.

The package is available for download if you'd like to work with it/run the tests yourself.