What New Features Does workerman v5 Bring to PHP Coroutines?

Introduction

workerman v5 was officially released on New Year’s Day 2025, and the accompanying webman framework and many plugins have been updated to support the new version. workerman is a well‑known PHP network container praised for its stability, in‑memory operation mode, multi‑process and multi‑protocol support.

Event‑driven library built on revolt/event-loop.

Coroutine functionality compatible with multiple coroutine implementations.

Background on Coroutines

The author defines a full coroutine solution as comprising context management, a scheduler, and an executor. Before native Fiber support, PHP could only simulate stack‑less coroutines with yield, which lacked proper scheduling and execution. Full coroutine implementations such as Swoole provide both asynchronous yield and modern Coroutine with event‑loop driving and rich context tools.

workerman also has an event loop, but it does not include coroutines because managing them is complex and the ecosystem around workerman is not yet unified enough.

Current Implementation in workerman v5

workerman v5 adopts revolt/event-loop as its event‑driven engine, introduces Fiber, and integrates the event‑driven engines of swow and swoole. This reduces fragmentation of PHP event‑loop solutions and enables three coroutine drivers within workerman v5.

What Can Coroutines Do?

Consider an asynchronous export task. The traditional flow is:

Frontend calls API → API creates task → task is pushed to a message queue. Message‑queue consumer processes export → updates task status. Frontend polls for task status and download link.

With coroutines, two alternative implementations avoid blocking the process.

1. Self‑Polling Consumption (blocking I/O still blocks)

public function test(): Response
{
    $id = 'your_file_id';
    // Get sharding count from request parameters
    $count = YourData::getShardingCount($request = request()->all());
    for ($i = 0; $i < $count; $i++) {
        // Retrieve data for each shard
        if ($data = YourData::getListBySharding($request, $i)) {
            // Append export data
            YourExcel::append($id, $data);
        }
        // Coroutine yields for 1‑10 ms
        Timer::sleep(rand(1, 10) / 1000);
    }

    return new Response(200, body: json_encode(YourExcel::getUrl($id)));
}

2. Self‑Polling Query

public function test(): Response
{
    $id = 'your_file_id';
    // Publish task to message queue
    YourMessageMQ::publish($id, $request = request()->all());
    while (1) {
        // Check consumption status
        if (YourMessageMQ::isComplete($id)) {
            break;
        }
        // Coroutine yields for 1‑10 ms
        Timer::sleep(rand(1, 10) / 1000);
    }

    return new Response(200, body: json_encode(YourMessageMQ::getReturn($id)));
}

Both approaches implement a long‑polling interface without heavily blocking the current process, reducing front‑end short‑polling resource consumption. Using Timer::sleep yields control to the event‑loop engine while preserving PHP’s native sleep / usleep semantics. Unlike Swow or Swoole, which hook system functions, this method cannot change the blocking behavior of existing blocking functions.

Future Outlook

PHP’s coroutine model is single‑threaded, so tasks must cooperatively yield within the event loop to remain non‑blocking. Most PHP ecosystem components are still blocking, limiting coroutine applicability. The author hopes more developers will contribute coroutine‑related libraries to broaden the ecosystem and revitalize PHP.

任重道远，也祝好