PHP 8.1 will land with Fibers support in some months. Supposedly, Fibers are meant to enable more performance on PHP applications, as long these are used instead of just shoving blocking code. It’s a novelty considering the single-threaded foundation of the language itself.
One of the thing that the RFC tells about is that Fibers are not a feature that should be directly exposed to the average developer, the one that actually puts the name on the project. Rather, this is for the code that is way up the call stack.
In other words, you won’t use Fibers directly.
They’re not meant for *you*
Fibers are still accessible to everyone in your project, but is not just a fire-and-forget procedure. Trying to manage multiple Fiber callbacks, and writing logic around delays, loops, and intervals, can be very cumbersome to make from scratch.
That’s why you don’t work with Fibers. There are async libraries that already made the plumbing for you.
This feature is primarily targeted at library and framework authors to provide an event loop and an asynchronous programming API. — PHP Fibers RFC
One thing these async libraries share in common is very simple: there are just building blocks for async tools. Your code is still somewhat blocking, and that includes Database queries, Files manipulation, Cache handling and HTTP Server Requests.
For example, retrieving results from a HTTP Request is still a blocking procedure. Shoving that code inside a “async function” just passes the ball to the same process. You need the underlying code to not push a result until it’s ready, instead of waiting for it, and that’s is pretty much the library or framework responsibility.
Fibers for libraries or frameworks
There are already very convenient packages built on top of async tools to make non-blocking code possible, like when using sockets or some databases. These use their own async core to allow coroutines to work in an async manner.
Unfortunately, PDO, which is used by all PHP projects, doesn’t support any async option or procedure.
The beneficiaries of Fibers will be tools that reuse a single PHP process. For example, we can see how RoadRunner or Swoole, tools allows a single PHP process to handle multiple requests, can benefit from a Fiber running in the background.
It’s not that Fibers are discouraged to be used directly, but rather, use async tools exposed by the packages you include in your project, or the frameworks themselves. Fibers will detach the callback waterfall from Generators (the
yield hell) or the
then() functions (the
callback hell). At the same time, Fibers will make asynchronous code feel synchronous and easy to understand.
We’re not too far away of frameworks including Fibers into their source code to manage async work that is usually blocking. The thing is not when, but how. The big four slowpokes (database, cache, file, HTTP) seem like the very first places to include async procedures that involve Fibers.
Luckily for us, Fiber is being worked on the latest versions of ReactPHP and amphp, so these are expected to have a common base and clean interoperability between them, and frameworks too.
Since Fibers are a very new concept on PHP, it’s very probable that we will see basic implementations that are meant to be easy to implement and understand. Soon we will be able to put something taxing in the background, and retrieve it later, which will be a procedure most applications will benefit on.