On the SitePoint PHP blog Thomas Punt has returned with more pthreads knowledge and shows you a few things to watch out for when upgrading from pthreads v2 to v3. pthreads is a PHP extension that allows for better process handling directly from PHP than just the built in proc_* functions.

A fair amount has changed for the pthreads extension with the release of pthreads v3. This article aims to cover the necessary information for those who are looking to upgrade their applications from pthreads v2 to v3.

If you’re unfamiliar with pthreads, check out my introduction to pthreads instead!

He starts with some of the more generic changes in this latest version with the most major being that it can now only be used in the command-line environment. Other changes were made to workers, method modifiers and the removal of some classes and methods. He also mentions some of the methods that were changed and some new classes/methods that were added. Overall he's of the opinion that, while some of the changes could make for headaches in the transition, v3 of the extension has "received a nice cleanup and is looking ever better."

In a post to the Madewithlove blog Maxime Fabre takes a look at threading in PHP using the pthreads support that can be included into your PHP installation.

As far as I can remember, PHP has always had a terrible reputation at handling very heavy (or asynchronous) tasks. [...] But PHP can do threading, and more importantly it's a lot easier than you probably think.

[...] In this article I'm going to dive into the pthreads extension (short for POSIX Threads). It has been around for a while (since 2012) but I feel like too many people forget it exists or assume it is going to be painful to use – mostly because the official documentation is rather slim about it.

They start by getting the pthreads support installed locally (it assumes you use OS X and the "brew" package manager but it can be installed manually too). The article starts off by defining some basic nomenclature from the pthreads world and gives a diagram of how it all fits together. From there it gets into some examples, showing a simple thread class to fetch Google results and how to fire off multiple instances at the same time. They then extend this even further and look at the concept of "workers" and using them to manage individual jobs. It then moves up the next level and looks at "pools" of workers and processing multiple workers at the same time.

There's also a section dealing with one "gotcha" that can happen with class inheritance between parent and child threads. They show how to work around this with a custom Worker class that performs the autoloading for you and is executed at the start of a Pool. Finally they cover the messaging between the child threads and, as a bonus, how threading could be used in a command bus setup.

In his most recent post Joe Watkins talks briefly about concurrency in PHP and some of the issues that can come along with it. This includes one of the most glaring: the stress it can put on the host system with even a small number of threads being introduced.

Before we start to cover the topic of how to achieve parallel concurrency in PHP, we should first think about when it is appropriate. You may hear veterans of programming say (and newbies parrot) things like: "Threading is not web scale." This is enough to write off parallelism as something we shouldn't do for our web applications, it seems obvious that there is simply no need to multi-thread the rendering of a template, the sending of email, or any other of the laborious tasks that a web application must carry out in order to be useful. But rarely do you see an explanation of why this is the case: Why shouldn't your blog be able to multi-thread a response ?

He gives an example of a controller request that spawns off just eight threads and imagines what might happen if that controller was requested even just one hundred times (resulting in 800 threads). He does point out at least one place where it could be useful, though: separating out the portions of the application that need to use the parallelism from the rest.

Parallelism is one of the most powerful tools in our toolbox, multicore and multiprocessor systems have changed computing forever. But with great power comes great responsibility; don't abuse it, remember the story of the controller that created 800 threads with a tiny amount of traffic, whatever you do, ensure this can never happen.

Jonathan Hill has posted the video of his recent presentation at the Atlanta PHP User Group, "Multi-tasking in PHP".

When it comes to multi-tasking and interacting with the operating system, PHP is no lightweight. In this December 6, 2012 presentation Jonathon Hill (@compwright) explores PHP's little-known POSIX, Process Control, and Semaphore extensions and shows you how to introduce a parallel dimension to your applications.

His presentation covers the use of multi-tasking to accomplish some common tasks in PHP (like batch processing or creating daemons). He talks about multi-processing vs multi-threading, forking, race conditions and semaphores.

You can watch the video of the presentation over on Vimeo and check out the software and links to other resources mentioned in the talk in this link bundle.

On the SitePoint PHP Blog today, Harry Fuecks takes a look at why PHP from a sysadmin's perspective.

A funny from the Python crowd: phpfilter—PHP "support" under CherryPy. There is a serious side to that though—it's spitting out something that looks like a PHP parse error—i.e. this is a developer problem (e.g. someone ftp’d a PHP straight onto their live web server for “testing”), not a runtime error.

More to the point, when was the last time you saw a PHP runtime error take down an entire application or web server? And no - "MySQL Connection Failed: Can't connect to local MySQL server" doesn’t count—PHP and the web server are still running—the MySQL server (or otherwise) is to blame.

He also looks at a slightly different method for serving up web applications - with FastCGI. He talks about the basic features of a server (forking, threading, asynchronous I/O) and how that explains how we've ended up with PHP being the "lesser of the evils"...

On the SitePoint PHP Blog today, Harry Fuecks takes a look at why PHP from a sysadmin's perspective.

A funny from the Python crowd: phpfilter—PHP "support" under CherryPy. There is a serious side to that though—it's spitting out something that looks like a PHP parse error—i.e. this is a developer problem (e.g. someone ftp’d a PHP straight onto their live web server for “testing”), not a runtime error.

More to the point, when was the last time you saw a PHP runtime error take down an entire application or web server? And no - "MySQL Connection Failed: Can't connect to local MySQL server" doesn’t count—PHP and the web server are still running—the MySQL server (or otherwise) is to blame.

He also looks at a slightly different method for serving up web applications - with FastCGI. He talks about the basic features of a server (forking, threading, asynchronous I/O) and how that explains how we've ended up with PHP being the "lesser of the evils"...