Freek Van der Herten has a new post to his site sharing a resource you can use to more easily keep up with PHP internals and RFCs - the externals.io service.

When features get added to PHP there’s a lot of discussion first about the new functionality. This is done on the so-called internals mailing list. You can try to follow the discussions via a rather ugly interface at http://news.php.net. The site looks like a very old school web email client where all conversations are just running through each other.

A couple of days ago Matthieu Napoli launched his new site externals.io. This site makes following internals a lot easier.

The externals.io site provides a clean interface to the discussions happening on the php.internals list, including nested threads and the ability to track unread messages. It definitely makes it simpler to keep track of the line of emails in a thread, but it's definitely read-only with no intent on being a full on mailing list replacement.

The SitePoint PHP blog continues their series looking at the features of the appserver.io project in this second post covering its server configuration, directory structure and how it handles threads during processing.

In the first part of our Appserver series, we discussed the very high level differences of Appserver’s architecture to standard web server stacks and got you up and running with an Appserver instance.

[...] In this part, we will be exploring the Appserver architecture a bit more in depth. We will go through the concepts of the different contexts and the parts of Appserver you get out of the box, which cover some of the ground most of the popular PHP frameworks offer. We will also configure the web server and look into an application’s structure. Once we are finished, you should have a fair understanding about Appserver’s contexts in relation to threading, the web server, and its setup.

They start with the threading functionality, showing how "contexts" come in to play and how the code executes as long as this context is alive. The post then gets into some of the code-related differences with using appserver such as extra annotation handling and AOP (aspect oriented programming) practices. From there they get into the tech behind the scenes: configuring the web server, setting up a virtual host and pointing it at the sample application. Finally they talk about the servlet engine and the server's directory structure underneath.

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.

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 Medium.com Dylan Bridgman has posted a tutorial with a few tips helping you improve the perceived load time of your application, the time between when the page starts loading and the user can first do something with its contents.

In this article I will concentrate on perceived load time. That is the time from when a page starts loading until the user is able to proceed. There have been other articles on this topic, some of which go into far more detail in some areas. My intention is to give a summary on the latest information and what you should be doing in PHP. I will link to additional information where applicable.

He breaks the advice up into three main categories: output buffering, multiple connections and using correctly structured pages. Under each section there's a few sub-points with more information, details on implementation and links to other additional information. He also includes an example that combines all of the advice into one PHP/HTML script outputting some basic content.

The PHP Women have started up a new contest today - their "I am" competition:

PHPWomen is delighted to announce the arrival of a new competition here at phpwomen.org. To win, all you have to do is complete this sentence: "I am a phpwomen member because..." and tell us how you got to where you are today and what brings you to the site. You should put your entry into the forum thread before the end of February.

There's no limits on who can enter ("women, men, aliens and pets") but posts that aren't in the general spirit of the competition woul dbe in danger of being deleted. The prize for the winner (besides the glory, of course) is a $50 USD gift certificate from the fine folks at php|architect.

Not a member yet? Find our more about it here!

New from Iain Dooley on the Working Software website today is his look at working with threading in PHP including forking and communication between the processes.

I recently wrote a little application that dumps a file across a forwarded port. [...] So when I first wrote it, I didn't know what I was doing and had never written socket code before, so it was a big procedural mess. Naturally I was keen to separate out my socket class into it's own package but this presented a problem: the controlling process needed to check the status but how could I decouple the process that instantiated the socket class from the socket code itself

So, he set about working up his class, hitting a few barriers along the way:

• Copy On Write issues with how PHP handles the variable for the forked process
• Interprocess Communication using Sockets using the socket_create_pair function
• a "Curious Interlude" about why you can share sockets between two processes

There's a example of it in action - a setup with a child process that's all set to count up and respond back with the current number to the managing script.

New from Iain Dooley on the Working Software website today is his look at working with threading in PHP including forking and communication between the processes.

I recently wrote a little application that dumps a file across a forwarded port. [...] So when I first wrote it, I didn't know what I was doing and had never written socket code before, so it was a big procedural mess. Naturally I was keen to separate out my socket class into it's own package but this presented a problem: the controlling process needed to check the status but how could I decouple the process that instantiated the socket class from the socket code itself

So, he set about working up his class, hitting a few barriers along the way:

• Copy On Write issues with how PHP handles the variable for the forked process
• Interprocess Communication using Sockets using the socket_create_pair function
• a "Curious Interlude" about why you can share sockets between two processes

There's a example of it in action - a setup with a child process that's all set to count up and respond back with the current number to the managing script.

In a new tutorial on the Developer.com website today, they explore the difference between (and the benefits and disadvantages of) the singleton pattern versus threading in a PHP application.

Although you probably could address some [of these] issues with the judicious use of synchronized blocks, do not overlook the utility of the ThreadLocal class. In this article, I will demonstrate the risk of not accounting for Threads when using a singleton pattern and show how simple it is to address.

They start with the creation of a ThreadLocal class, one that allows the developer to communicate with the threads, and its usage. In contrast, they also create the Singleton class, showing the creation method of multiple objects of the same type.

They do, however, point out an issue that the threaded method has - unreliable results. Help is on the horizon, though, in the form of a HelperFactory class to manage the connections a bit more efficiently.

In a new tutorial on the Developer.com website today, they explore the difference between (and the benefits and disadvantages of) the singleton pattern versus threading in a PHP application.

Although you probably could address some [of these] issues with the judicious use of synchronized blocks, do not overlook the utility of the ThreadLocal class. In this article, I will demonstrate the risk of not accounting for Threads when using a singleton pattern and show how simple it is to address.

They start with the creation of a ThreadLocal class, one that allows the developer to communicate with the threads, and its usage. In contrast, they also create the Singleton class, showing the creation method of multiple objects of the same type.

They do, however, point out an issue that the threaded method has - unreliable results. Help is on the horizon, though, in the form of a HelperFactory class to manage the connections a bit more efficiently.