[VOTE] True Async RFC 1.6

To correct a mistake in previous email, there was an error in the second code snippet of my last email. The correct code is as follows:

<?php
Co\run(function() {
    Co\go(function() {
        $fp = stream_socket_server("tcp://0.0.0.0:8000", $errno, $errstr, `STREAM_SERVER_BIND` | STREAM_SERVER_LISTEN);
        while(1) {
            $conn = stream_socket_accept($fp);
            Co\go(function() use ($conn) {
                while(1) {
                    fwrite($conn, 'The local time is ' . date('n/j/Y g:i a'));
                    sleep(1);
                }
            });
        }
    });


    $n = 2000;
    while($n--) {
        Co\go(function() {
            $fp = stream_socket_client("tcp://127.0.0.1:8000", $errno, $errstr, 30);
            while(1) {
                echo fread($fp, 8192), PHP_EOL;
            }
        });
    }
});

The logic here is to start a server coroutine, which then accepts client connections. Each new connection spawns a coroutine that sends the current time string to the client every second.

The code below directly creates 2,000 clients in the current process, connects them to the server, and reads data. Note: If you want to test this code, I recommend lowering the number of concurrent connections, otherwise your terminal may freeze or become unresponsive.

This program can accommodate virtually any PHP function, such as mysqli, pdo, redis, curl, and more—all of which can be executed concurrently with ease.

Notice that only two new APIs have been introduced in the code: Co\run and Co\go; the rest are standard or commonly used PHP extension functions.

This is precisely the strength of Swoole, and the focus of the True-Async team’s ongoing work.

Hopefully, the PHP language will one day include such powerful features natively.

Tianfeng Han

 
------------------ Original ------------------
From:  &quot;韩天峰"<rango@swoole.com>;
Date:  Fri, Nov 21, 2025 07:03 PM
To:  "Edmond Dantes"<edmond.ht@gmail.com>; "Rowan Tommins [IMSoP]&quot;<imsop.php@rwec.co.uk>;
Cc:  "php internals"<internals@lists.php.net>;
Subject:  Re: [PHP-DEV] [VOTE] True Async RFC 1.6

My thanks to Edmond for his work on PHP async I/O. Regardless of how the vote turns out, I believe everything is moving in a positive direction. This will undoubtedly leave a bold mark in the history of PHP’s evolution.

I’ll share some information and thoughts to help everyone understand async. These may include views on PHP Fiber, amphp, reactphp, and FrankenPHP, but please remember they are purely technical reflections, with no praise or criticism implied.

1. What lies at the core of Swoole’s async design
   Using Boost.Context assembly to implement C/C++ stackful coroutines is no longer esoteric; PHP Fiber and Swoole are almost identical in their low-level principles. The only difference is that Swoole suspends and resumes coroutines entirely in C/C++, whereas PHP Fiber does the opposite—suspension happens in PHP code. While PHP also exposes relevant APIs, they are rarely used in Swoole.

Because both the C stack and the PHP stack are fully preserved, this approach is actually very safe and won’t cause memory errors—unless static or global memory is misused. Swoole runs over 1,700 tests on GitHub Actions, many of which involve multiple coroutines issuing concurrent requests. Before testing, containers spin up mysql, pgsql, oracle, redis, firebirdsql, httpbin, tinyproxy, pure-ftpd, and many other databases and servers to interact with code in phpt files. The breadth of these tests speaks to its reliability.

Unlike amphp/reactphp, Swoole does not invent new APIs; it reuses PHP’s existing functions. Swoole hooks into PHP streams, the standard library, and other extension functions—such as sleep, stream_socket_client, stream_socket_server, file_get_contents, fsockopen, curl_*, mysqli, pdo_mysql. Inside a Swoole coroutine, these calls are no longer synchronous blocking I/O; they become non-blocking. When I/O isn’t ready, the runtime suspends the current coroutine and uses epoll to watch for readable events, resuming the coroutine only when the operation completes.

An example:

Co\run(function() {
    Co\go(function() {
        while(1) {
            sleep(1);
            $fp = stream_socket_client("tcp://127.0.0.1:8000", $errno, $errstr, 30);
            echo fread($fp, 8192), PHP_EOL;
        }
    });

    Co\go(function() {
        $fp = stream_socket_server("tcp://0.0.0.0:8000", $errno, $errstr, STREAM_SERVER_BIND | STREAM_SERVER_LISTEN);
        while(1) {
            $conn = stream_socket_accept($fp);
            fwrite($conn, 'The local time is ' . date('n/j/Y g:i a'));
        }
    });

    Co\go(function() {
        $redis = new Redis();
        $redis->connect('127.0.0.1', 6379);
        while(true) {
            $redis->subscribe(['test'], function ($instance, $channelName, $message) {
                echo 'New redis message: '.$channelName, "==>", $message, PHP_EOL;
            });
        }
    });

    Co\go(function() {
        $redis = new Redis();
        $redis->connect('127.0.0.1', 6379);
        $count = 0;
        while(true) {
            sleep(2);
            $redis->publish('test','hello, world, count='.$count++);
        }
    });
});

By conventional understanding, this code shouldn’t run: every function that performs network I/O would block the entire process. But in the Swoole environment, the program runs smoothly. We can even modify the code to increase the number of clients by several thousand, and it still runs stably.

Co\run(function() {
    Co\go(function() {
        while(1) {
            sleep(1);
            $fp = stream_socket_client("tcp://127.0.0.1:8000", $errno, $errstr, 30);
            echo fread($fp, 8192), PHP_EOL;
        }
    });

    $n = 2000;
    while($n--) {
        Co\go(function() {
            $fp = stream_socket_server("tcp://0.0.0.0:8000", $errno, $errstr, STREAM_SERVER_BIND | STREAM_SERVER_LISTEN);
            while(1) {
                $conn = stream_socket_accept($fp);
                fwrite($conn, 'The local time is ' . date('n/j/Y g:i a'));
            }
        });
    }
});

Swoole’s aim is to leverage PHP’s existing ecosystem rather than build a new one. If we were starting from scratch—discarding PHP’s commonly used functions and learning an entirely new async API—why wouldn’t developers simply switch languages?

Now that true-async has adopted Swoole’s approach, I think that’s an excellent choice.

2. Where PHP-FPM falls short

If all you do is read/write MySQL and generate HTML, PHP-FPM is already superb. If I’m building a web project that only depends on MySQL, I wouldn’t use Swoole; PHP-FPM is the best choice. But many modern web projects need to call external HTTP APIs, and slow requests often render PHP-FPM unavailable, which is frustrating. Async exists precisely to address this. With the rise of ChatGPT, streaming responses such as SSE and full-duplex communication via WebSocket will become increasingly common—technologies that PHP-FPM doesn’t support well. Many developers choose Node.js or Go instead. The influence of Swoole or amphp remains limited; only a small subset of developers opt to stay with PHP for async programming using these solutions.

If PHP can adopt true-async or other AsyncIO solutions and provide support for async I/O at the language level, it would be tremendous news for PHP users. In essence, async I/O is a runtime matter—much like Node.js in relation to V8. New PHP syntax isn’t required; Swoole, for instance, adds no new syntax—just some functions and classes—just as fastcgi_finish_request and fpm_get_status are php-fpm–only functions.

3. FrankenPHP
   FrankenPHP is a wonderful project that uses Go to give PHP additional capabilities, with great room for exploration.

In an RFC for a Polling API, author Jakub Zelenka—also a FrankenPHP maintainer—shared a technical idea: consider implementing a goroutine version of the TSRM thread isolation scheme. Each goroutine would have its own Zend VM environment—essentially a goroutine-based php-fpm.

I believe this approach may pose significant challenges, especially regarding memory resources.

Today, when running Symfony or Laravel under PHP-FPM with 100–200 worker processes, memory pressure is already heavy. If each process consumes tens to over a hundred megabytes, the group can easily use up to 20 GB. With goroutines, if you launch thousands or tens of thousands to handle requests concurrently, memory usage could become enormous.

By contrast, coroutines are designed to be very lightweight: a suspended coroutine should retain only the call stack and a small amount of request/session-related memory, while other resources can be shared and reused across requests. This drastically reduces memory usage while still allowing a large number of simultaneous requests. When a request is slow, suspension incurs little cost.

4. Fiber
   If Fiber and coroutines coexist as execution units, I agree it can be confusing. But the current Fiber simply can’t be used in a Swoole-like runtime with extensive low-level switching.

Although Fiber landed in PHP 8.1, Swoole cannot use any Fiber APIs.

In addition, Fiber doesn’t fully switch all global memory state—for example OG(handlers), BG(serialize), BG(unserialize)—so it’s unclear whether issues exist there.

5. Golang’s abundance of synchronization primitives

Go’s goroutine isn’t purely a coroutine; it’s a combination of thread and coroutine, which necessitates many locks, mutexes, semaphores, and atomics to resolve data races. PHP does not support multithreading. Whether it’s Fiber, Swoole, or any other coroutine implementation in PHP, execution is single-threaded: only one coroutine runs at a time, and until it yields, no other coroutine runs.

Therefore, PHP coroutines are not a complex concept but a clear and straightforward one.

If the true-async RFC vote doesn’t pass this time, I think we can split the work into several parts, aiming for each RFC to accomplish just one thing.

I think the most important task now is to allow coroutine switching in low-level C code, not just in PHP code. Whether we call it coroutines or Fiber 2.0 is fine. On top of that, other work can be introduced via future RFCs to progressively strengthen the design.

Lastly, I sincerely hope PHP keeps getting better. Thanks all for your contributions. Open discussion is always beneficial.

Tianfeng Han

------------------ Original ------------------
From:  "Edmond Dantes"<edmond.ht@gmail.com>;
Date:  Fri, Nov 21, 2025 03:17 PM
To:  "Rowan Tommins [IMSoP]&quot;<imsop.php@rwec.co.uk>;
Cc:  "php internals"<internals@lists.php.net>;
Subject:  Re: [PHP-DEV] [VOTE] True Async RFC 1.6

Hello.

Imagine that we have an application like this.

class AuthService
{
    private static ?self $instance = null;

    private PDO $db;
    private ?string $sessionId = null;

    // Private constructor for singleton
    private function __construct(PDO $db)
    {
        $this->db = $db;
    }

    // Get singleton instance
    public static function getInstance(PDO $db): self
    {
        if (self::$instance === null) {
            self::$instance = new self($db);
        }
        return self::$instance;
    }

    public function login(string $email, string $password): bool
    {
        // Find user by email
        $stmt = $this->db->prepare('SELECT * FROM users WHERE email = ?');
        $stmt->execute([$email]);
        $user = $stmt->fetch(PDO::FETCH_ASSOC);

        // Invalid credentials
        if (!$user || !password_verify($password, $user['password_hash'])) {
            return false;
        }

        // Generate and save session ID
        $this->sessionId = bin2hex(random_bytes(16));

        $stmt = $this->db->prepare(
            'INSERT INTO sessions (user_id, session_id) VALUES (?, ?)'
        );
        $stmt->execute([$user['id'], $this->sessionId]);

        return true;
    }

    // Return current session ID
    public function getSessionId(): ?string
    {
        return $this->sessionId;
    }
}

One day you decide you want more performance and make a single PHP
process handle multiple connections concurrently. You wrap each
request in a separate coroutine and try to use the old code.

$server = new Swoole\Http\Server("127.0.0.1", 9501);

$server->on("request", function ($req, $res) {

    // create DB connection (just for example)
    $db = new PDO('mysql:host=localhost;dbname=test', 'root', '');

    // get singleton
    $auth = AuthService::getInstance($db);

    // read request data
    $data = json_decode($req->rawContent(), true);

    $email = $data['email'] ?? '';
    $password = $data['password'] ?? '';

    // call old sync code
    $ok = $auth->login($email, $password);

    if ($ok) {
        $res->end("Logged in, session: " . $auth->getSessionId());
    } else {
        $res->status(401);
        $res->end("Invalid credentials");
    }
});

$server->start();

What is happening here?
Now, in PHP, inside a single process or thread, the same code is
literally handling multiple connections.
At the same time, there are constant switches between different
requests at the points where MySQL queries occur.

That is, when the code executes
$stmt->execute([$email]);
control is passed to another coroutine with a different
$stmt->execute([$email]);

What breaks in this code?
Correct, coroutines break the singleton because they alternate writing
different Session IDs!

And what does not change in this code?
The SQL queries can remain unchanged.

The first problem with shared memory between coroutines can ONLY be
solved by the programmer. Only the programmer. There is no solution
that would make this happen automatically.
Yesterday we talked about how we can help the programmer detect such
situations during debugging. But in any case, only the programmer
CAN and MUST solve this problem.

The difference is that you don’t need to rewrite everything else.
The focus is only on the issue of concurrent access to memory.

The essence of the choice is how much code needs to be rewritten.
Almost everything, or only the code with global state.
My choice is: it’s better to rewrite only the code with global state —
or switch to Go and avoid the pain :)

As for the rest, I will write a separate message so as not to clutter things up.

Edmond

Hello,

Thank you a lot.

Swoole’s aim is to leverage PHP’s existing ecosystem rather than build a new one. If we were
starting from scratch—discarding PHP’s commonly used functions and learning an entirely new
async API—why wouldn’t developers simply switch languages?

And it turned out to be a very successful solution, which has been
proven many times in practice.
The first question developers ask when they want to migrate to async
is: how much code do I need to rewrite?
If the cost of migration is comparable to rewriting the entire project
from scratch, then it becomes economically more sensible to hire Go
developers and rebuild the project.

And PHP’s influence is strong primarily because of the companies that
run PHP-based projects.
So when a company decides to rewrite a project in another language
because PHP no longer meets its technical needs, PHP loses that
client.
That’s why supporting a single runtime and a single API,
standardization, is crucial for the technology’s survival.

Those were the economic reasons. There are technical reasons as well.
In a server that handles multiple requests within a single thread, it
is very important that coroutines do not occupy the CPU for too long.
If they do, all coroutines in that process are affected.
This means that having blocking operations inside a coroutine
nullifies the advantages of concurrency.
Therefore, intentionally making functions blocking so that code works
correctly with shared memory makes the idea of using asynchronous code
pointless.

This does not mean that one solution or another is 100 percent
perfect. Each has its drawbacks. The question is whether the drawbacks
outweigh the benefits.
Swoole made it possible to see that, in practice, using a unified API
provides a significant advantage that makes migrating legacy projects
feasible.
This means that by voting for an RFC built on these principles, we are
not venturing into a dark unknown, but walking along a well-trodden
path.

Ed

Hello

I think you seriously underestimate impact of this in the current PHP code bases where many applications depend on global state.
Do I really look like someone who could underestimate memory-related issues? :)

Now imagine that some popular plugin decides to use async which change some of its globals (like $post or $wp_query) during the suspension of the main code. I would assume this could horribly break things.
Or for example, you run an old WordPress on the new PHP 8.5 and
everything breaks. Is that a reason not to release new PHP versions?
No, I’m not joking. That’s literally the essence of the argument. If
something might break, then we shouldn’t do it?

This is a common story. There is a framework that is adapted to a
technology, and there is a framework or library that is not adapted to
it.
If a framework is not adapted, you simply won’t be able to use the
technology. So why is this considered a problem?
However, inside WordPress you will still be able to use coroutines as
long as you don’t call WP functions that aren’t adapted. You can. So
why is this a problem?

I can use AMPHP inside WordPress and break WP.
So does that mean we must urgently remove Fiber from the language?
Because AMPHP uses Fiber, and AMPHP implements coroutines. And
coroutines break WordPress.
Asynchrony already exists in PHP. You can write async code today.
Which means you can already do all the “horrors” you’re talking about.
TrueAsync cannot change that. And no one else can change it either.
So why is this being treated as an argument against it?

Don't forget that other code don't have control over the plugin and it might not even know that async is used there.
Exactly. This means that right now I can use Fiber plus select() to
write async code and break WordPress.
And I can also write a plugin that divides by zero and crashes
WordPress, and WordPress won’t know anything about it.

So I'm not sure if this design is compatible with WordPress

Yes, WordPress is not compatible with asynchrony. I’ll emphasize
again. This is not about TrueAsync specifically. This is about
asynchrony itself. Yes, WordPress and Laravel are not compatible with
concurrent execution. That’s true.
But are you really suggesting that because of this, all other
applications should be denied the ability to use it?
Moreover, would you deny WordPress itself the possibility of
supporting asynchrony in future? After all, WordPress can be
refactored. It’s not carved in stone.

Wouldn’t WordPress benefit from the performance improvements that
async provides?
Wouldn’t WordPress plugins benefit from being able to actively
communicate with microservices and deliver the fastest possible
responses to JavaScript?

Is this feature really something nobody needs? If yes, then I have no
further questions.

Async is needed to increase throughput. That’s the purpose. If a PHP
project doesn’t need it, it doesn’t have to use it. That’s fine. But
there are PHP projects that do need it.

As for next lines:

1. Disallow suspension of the main sync code which is effectively some sort of colouring.
2. Preventing access to globals from coroutine which I'm not sure is even fully doable from the engine PoV

Yesterday there was a small discussion about debugging capabilities in
PHP for async.
For example: throwing an error if more than one coroutine writes to a variable.
Or issuing a warning if someone creates a coroutine inside a function.

This can be called an extended debugging mode. Almost no other
language has this, and if we implement it, it would be very cool and
very useful.

We can also come up with other ways to protect PHP users from silly mistakes.
For example, blocking async entirely or per namespace.
But I don’t think discussing these features is the top priority right now.
All of this is nice to have once everything else is already in place.

Hey Jakub,

Hi,

I think you seriously underestimate impact of this in the current PHP
code bases where many applications depend on global state. Especially
the legacy ones but even the most popular ones. Just look into
WordPress which use global state extensively. Now imagine that some
popular plugin decides to use async which change some of its globals
(like $post or $wp_query) during the suspension of the main code. I
would assume this could horribly break things. Don't forget that other
code don't have control over the plugin and it might not even know
that async is used there. So I'm not sure if this design is compatible
with WordPress and similar applications where global state is used
extensively. If that's the case, it's of course a problem because
those applications (well WordPress on its own in fact) compose the
majority of PHP users so introducing something that would have
potential to break its code would limit usability of the whole feature
and could even lead to loosing more users that we could gain from
introducing this feature.

So I think it will need to find some solution that will prevent this
from happening. I guess there might be few options

1. Disallow suspension of the main sync code which is effectively some
   sort of colouring.
2. Preventing access to globals from coroutine which I'm not sure is
   even fully doable from the engine PoV - it would mean some sort of
   different execution mode that could not use globals (e.g. global
   keyword and calling some functions that change global state). It would
   need channels for communications between coroutines. The advantage of
   such model would be possibility to combine it with threads in the
   future but I could imagine it could still lead to some subtle issue
   for years as there is internal global state as well that can lead to
   some surprises. But maybe that would be worth it.

I think you seriously misunderstand this.

Async does not allow you to introduce some effects from the outside. You
have to actively opt-in to running stuff in parallel.

The problematic part, is, when you call code inside of coroutines, which
is not safe to be run in parallel with other code.

I.e. if you start writing code like await([new Coroutine(fn() => not_safe_to_run_twice()), new Coroutine(fn() => not_safe_to_run_twice())]) (pseudo code).
Where not_safe_to_run_twice() shares some context.

So, when you write async code, you have to know that the called code
is allowed to run in parallel with any other code which you explicitly
chose to run in parallel with it. E.g. if you'd run two wordpress
functions which don't have side-effects (not even to internal state),
then you're perfectly fine doing that. If you run wordpress functions in
parallel which may jump back to the scheduler during its operation and
leave the internal state in some intermittently invalid form, then yes,
then you have a problem.

But if your goal is to just do a localized parallelized operation which
you know is safe to run in parallel - e.g. some image processing and
storing some stuff in the database, within your wordpress plugin, that's
absolutely fine. It won't break anything.

Essentially: Just don't call stuff in parallel which you don't know is
safe to be called in parallel and you're golden.

Bob