Sergey Zhuk has a post to his site covering concurrency including some of the basic concepts and how promises and coroutines come in to play.

What does concurrency mean? To put it simply, concurrency means the execution of multiple tasks over a period of time. PHP runs in a single thread, which means that at any given moment there is only one bit of PHP code that can be running. That may seem like a limitation, but it brings us a lot of freedom. We don’t have to deal with all this complexity that comes with parallel programming and threaded environment. But at the same time, we have a different set of problems. We have to deal with concurrency. We have to manage and to coordinate it.

He goes on to talk about parallel requests, cross-request needs and the requirement for coordination. He then covers the subject of promises, briefly defining it and giving an example of creating a basic promise in ReactPHP. Following this he talks about the other main topic of the article: using PHP generators along with parallel requests to only create the responses when yielded.

In a new post to his site Sergey Zhuk takes a look at generators in PHP and shows how they're integrated into coroutines and promises to help with the chunked asynchronous processing.

Generators become available in PHP since version 5.5.0. The main idea is to provide a simple way to create iterators but without creating a class that implements Iterator interface. A generator function looks like a normal function, except that instead of returning the result once, a generator can yield as many times as it needs to in order to provide the values to be iterated over.

[...] So, let’s wrap up what we know about generators:

• interruptible/resumable functions
• use yield rather than (or in addition to) return
• values/exceptions can be send/thrown into
• behave like iterator

All these generator features are used in <a href="https://amphp.org/>Amp to implement coroutines.

The post starts out with a pretty detailed look at generators in PHP and the functionality they offer. It covers sending values into the generator, exception handling and the use of the yield statement. It then moves over to describing coroutines, promises and deferred handling. Generators make it easier for them to chunk up the operation one piece at a time rather than requiring all data up front.

In a new post to his site Cees-Jan Kiewiet has posted in introduction to using asynchronous processing in your PHP application by using RecoilPHP and ReactPHP.

Getting your mind wrapped around async nature can be mind bending at first. But with RecoilPHP you can write code promise as if you're writing sync code.

He starts with some sample code showing the difference between normal ReactPHP and how the same kind of thing would be written using RecoilPHP. He then gets into the setup of a project that includes the RecoilPHP package and several others from React. With that base set up, he shows how to create a promise that opens a socket and listens on it for incoming messages and how to modify it to add additional coroutines. Finally he shares a few "bonus tips" and covers error handling.

Sergey Zhuk has posted another article to his site covering functionality provided in ReactPHP. In this latest tutorial he covers the PromiseStream handling of the library allowing for the translation from promise to stream (and back).

One of the patterns that are used to deal with streams is spooling: we need the entire resource data available before we start processing it. One approach is to collect each chunk of data received from the stream.

But, imagine that we have some client code that wants to process some data from a file. It doesn’t care about the streams, it only needs to receive the entire data from the file. With this approach, this code should be called inside the callback for the end event of the stream. So, the client code should now about streams, events, and callbacks. But sometimes it’s impossible.

Example code is included to illustrate the problem above and an answer is provided in the form of ReactPHP promises. This allows the data to move into the promise as the data is being read from the stream's source. The tutorial goes on to talk about the functionality behind this transition including the buffer method to create the promise with chunked data, the all method to build the promise from the full data in the stream and the first method that works with events on the stream. The article then covers the reverse, showing how to pull information from a promise and push it back out to a stream via the unwrapReadable and unwrapWritable methods.

Sergey Zhuk has written up a tutorial showing you how to implement promise-based caching with ReactPHP, a continuation of a previous post.

In the previous article, we have already touched caching (when caching DNS records). It is an asynchronous promise-based Cache Component. The idea behind this component is to provide a promise-based CacheInterface and instead of waiting for a result to be retrieved from a cache the client code gets a promise. If there is a value in a cache the fulfilled with this value promise is returned. If there is no value by a specified key the rejected promise returns.

He starts by defining the caching interface and how it would look in use to set/get a cache value. He shows how to update this with a "done" handler to output the value when the get is complete. He continues on showing how to use a fallback handler: either "otherwise" or "then". He also shows how these can be chained together to make more complex operations. The post ends with an example of this caching component in action and links to other library that use the same ideas.

Sergey Zhuk has a new post to his site continuing on from a previous article about promises in ReactPHP. In this latest post he shows how you can use timers to cancel the execution of promises if their execution time grows too large.

At first, let’s refresh in memory what is Promise. A promise represents a result of an asynchronous operation. You can add fulfillment and error handlers to a promise object and they will be invoked once this operation has completed or failed. Check this article to learn more about promises.

Promise is a very powerful tool which allows us to pass around the code the eventual results of some deferred operation. But there is one problem with promises: they don’t give us much control.

He then shares the code required to make a simple "Hello world" promise and a handler for when it's cancelled. He then shows how to use the PromiseTimer functionality in ReactPHP to set a timeout on the promise instance and automatically call the cancellation event when it reaches that limit. He also includes a reminder that, in the cancellation handling of the promise it's a good idea to close out and cancel any other resources that may have been in use. The post ends with an example of how you can stack other functionality on the timeout using methods like "then" and "otherwise".

Michael Dowling has a new post to his site today talking about the latest release for the Guzzle HTTP library and how it now works with RingPHP to make integration life easier. The RingPHP library, inspired by Clojure's Ring library, provides a low-level structure to work with HTTP clients and servers through a simple interface.

With RingPHP, Guzzle does not require cURL and can be used with any HTTP transport mechanism. I’d love to help anyone who is interested in creating RingPHP adapters to bind Guzzle to another library. For example, WyriHaximus on Github is working on binding Guzzle to ReactPHP. (In fact, Guzzle 4 did not require cURL, though it was much harder to use an alternate transport.)

He goes on to talk more about the changes in the Guzzle 5 release including more detail on the RingPHP integration, the use of promises/futures and iterable and callable streams. There's also several new events included in the release as well. He finishes out the post with an upgrade guide to help make the transition easier.

On the Zend Developer Zone today, Andi Gutmans has written up a new post that, in light of a recent announcement from Microsoft about "going open source" with some of their products, asks what it means for the web and for the PHP community specifically.

Today Microsoft announced a significant initiative which aims to provide the developer community with access to a large number of Microsoft protocols and file formats. [...] With Microsoft opening up their specifications under the OSP, open-source communities like Zend Framework are now able to build such solutions without fear of litigation. There are many other areas where it will benefit open-source projects including Samba (SMB), FreeTDS (SQL Server), Mono (.NET), and others...

He shares his thoughts on the winners (Microsoft themselves, Open Source community) and losers (Microsoft's competitors, Linux) on the deal and the beneficial impact he thinks it will all have on the PHP.

In this new post from Marco van Hylckama Vlieg, he asks a question of his readers - "Which PHP framework holds a promise for the future?"

I thought I'd throw in a question for a change! As I'm quite sure at least some of my readers are skilled PHP developers, some of them might be able to throw in some insightful remarks when it comes to the future of PHP5 and frameworks.

He mentions developers that are tired of "plumbing code" (the guts of the app), but havent found something in the PHP realm that fits. He mentions three frameworks specifically; Symfony, WASP, CakePHP.

In this new post from Marco van Hylckama Vlieg, he asks a question of his readers - "Which PHP framework holds a promise for the future?"

I thought I'd throw in a question for a change! As I'm quite sure at least some of my readers are skilled PHP developers, some of them might be able to throw in some insightful remarks when it comes to the future of PHP5 and frameworks.

He mentions developers that are tired of "plumbing code" (the guts of the app), but havent found something in the PHP realm that fits. He mentions three frameworks specifically; Symfony, WASP, CakePHP.