Understanding PHP 8.1 Fibers: Theory, Practical Use, and Limitations

This translated article (original at https://stitcher.io/blog/fibers-with-a-grain-of-salt) introduces PHP 8.1 Fibers, starting with a basic example that sends asynchronous HTTP requests and processes them in parallel.

The RFC warns that the Fiber API should not be used directly in application code; it is a low‑level flow‑control primitive intended for higher‑level abstractions.

The author first explains the concept of fibers, why they are rarely used directly in application code, and how asynchronous PHP works.

Using a simple diagram, the article contrasts synchronous execution (send → wait → process → repeat) with parallel execution where requests are sent without waiting, and the program periodically checks for completed responses, reducing overall execution time.

Fibers in PHP 8.1 provide a more efficient way to manage these parallel execution paths compared to generators, allowing code to start, pause, and resume isolated execution flows within the same process.

However, fibers do not introduce true asynchronous I/O; they run in a single PHP process and only one fiber executes at a time, requiring an event loop to poll for completed operations.

Most PHP I/O functions are blocking; only a few support non‑blocking mode. The article shows a socket example that creates a non‑blocking pair:

[$read, $write] = stream_socket_pair(
    STREAM_PF_UNIX,
    STREAM_SOCK_STREAM,
    STREAM_IPPROTO_IP
);
stream_set_blocking($read, false);
stream_set_blocking($write, false);

Implementing three parallel HTTP requests with raw sockets would require a custom HTTP implementation, which the author advises against. Instead, existing async frameworks such as Amp or ReactPHP should be used.

Using ReactPHP, the same task can be written succinctly:

$loop = React\EventLoop\Factory::create();
$browser = new Clue\React\Buzz\Browser($loop);
$promises = [
    $browser->get('https://example.com/1'),
    $browser->get('https://example.com/2'),
    $browser->get('https://example.com/3'),
];
$responses = Block\awaitAll($promises, $loop);

This approach abstracts away the low‑level fiber handling, aligning with the RFC’s intent.

The article then compares fibers to generators, noting that each fiber has its own call stack, allowing suspension deep inside nested calls without changing return types, unlike generators which must return a Generator instance.

While fibers improve syntax and flexibility, they are still less powerful than Go’s goroutines, and many PHP functions lack non‑blocking capabilities, limiting the mainstream adoption of async PHP without additional frameworks.

The author concludes that unless you maintain an async PHP framework, Fibers alone offer limited value, though they represent a step forward, especially when combined with extensions like Swoole that provide true non‑blocking I/O.