Async use cases

[EdmondDantes]

In this thread you may share examples of tasks you have already solved using async in PHP, or tasks that would be easier to solve with it.
You may include code examples if you wish.
This topic may become useful for shaping the API.

You will also help other PHP developers learn something new or look at old problems from a different perspective.
That’s why this thread can be extremely useful for everyone!

[danog]

IMO this is a given (otherwise we wouldn't even be having this discussion), but since it wasn't spelled out, concurrency allows for:

• Higher performance with entirely local caching
• HIgher performance by concurrent execution of I/O (read, write files at the same time, increasing throughput; fetch multiple URLs at the same time, over a single http/2 connection, increasing throughput and removing overhead (curl_multi_init was added for this reason))
• Much easier background execution of tasks
• Higher request throughput, due to the greatly reduced setup overhead per-request (non-async worker-mode can also help, but concurrency has the added performance benefit of reducing context switches)

Other languages have introduced concurrency for these reasons and many more, PHP is the only one left behind, and that's all there is to it.

[macropay-solutions]

1. Eloquent's eager loading executes in sync, one select per relation. When there are multiple (>30 relations), async would allow them to be executed async and then only their results will be parsed/loaded sync into the model.
   That would shorten the time needed for retrieving the data from QT1 + QT2 + ... + QT30 to MAX(QT1, QT2, ... , QT30). The hydration will take the same amount of time.

2. When importing CSVs and dispatching them in batches of 10 rows each (for example), to be processed in a queue job, that job could start processing async all 10 rows at once.

3. When updating a composed resource via API, you have to update the main table from DB and then its 1:1 related tables. If the updates can be made without a DB transaction, then in theory all involved tables could be updated async from a middleware.

This is if the async would not be restricted to single thread(worker). See related question about this.

[EdmondDantes]

Today I ran into a task where async would be useful.
The task: implement a progressive delay when entering a password.
The solution: if you call sleep in a regular PHP script, it keeps an entire worker occupied. If you use this approach, an attacker can easily flood the server. All they need is a few parallel threads trying wrong passwords, and the worker pool will be exhausted very quickly.

For a stateful server using coroutines, such a delay costs far fewer resources. At the same time, a stateful server gains additional options for preventing this type of attack, because the server knows all its connections and operations and can be optimized accordingly.

[ioweb-gr]

This maps directly to webhook delivery with exponential back off.

A common scenario is sending a callback to an ERP after a job completes. If the ERP responds with 429 you have to retry later. At the moment the only options are to republish the message with a delay block the worker with sleep or rely on cron based retry logic.

With coroutines the worker can keep the task alive and simply yield during the back off window while continuing to process other webhooks. When the delay expires the coroutine resumes and retries. This removes worker blocking reduces queue churn and makes the whole pipeline far more resilient.

Both cases deal with delaying execution without blocking a worker so the task can wait while the system keeps handling other work which is exactly what coroutines enable.

[marius-ciclistu]

Keeping alive so many sleeping PIDs will not have negative consequences? What if a SIGTERM arrives because of a scale down or deploy scenario? You have to dispatch a job for each sleeping PID. Risky...

[EdmondDantes]

This maps directly to webhook delivery with exponential back off.

Yes, this is one of the typical scenarios that PHP is currently missing.

[EdmondDantes]

Keeping alive so many sleeping PIDs will not have negative consequences? What if a SIGTERM arrives because of a scale down or deploy scenario? You have to dispatch a job for each sleeping PID. Risky...

Of course this would be a problem, which is why I’m saying that PHP cannot handle such scenarios at all.

[Gemorroj]

As an example, I want to describe a problem that I've been unable to solve for a long time using existing methods within an old Symfony project.

We need to calculate delivery costs from multiple carriers (UPS, FedEx, DHL, and many others). Currently, calculations are performed sequentially - first we calculate for one carrier, then the second, and so on, with no parallelism. This creates a huge performance penalty.

The calculation code is very large and complex (background HTTP requests, smart packaging logic, distance calculations, specific user restrictions, and many other factors).

The core problem is that when we try to parallelize this work, we need to pass serializable data to each worker. As far as I know, most parallel processing tools in PHP serialize data to pass it between workers (at least in cases where the project isn't originally built on Swoole/Amp/ReactPHP, where non-serializable data sharing might be possible - I'm not entirely sure about this).

In my project, I cannot properly prepare data for serialization because:

• There's too much data involved
• The preparation process itself is resource-intensive
• Reconstructing working objects in workers would be equally expensive
• I need access to the full Symfony container with all its services (database connections, HTTP clients, repositories, configuration)

Here's a simplified example: https://github.com/Gemorroj/parallel-nonserializable/blob/master/src/Test.php
In this case, we get an error because Amp cannot serialize the Symfony HTTP client. This is logical but fatal for my use case.

I have hope that this RFC could help solve problems like mine in projects with classic synchronous architecture. Options like pthreads might theoretically work, but as far as I know, that project is essentially abandoned (partly due to conflicts with fibers). Additionally, it requires ZTS PHP.

The ideal solution would be something like pcntl_fork functionality but available outside of CLI mode.

[marius-ciclistu]

This RFC model with a single thread and multiple coroutines could use the time needed for outside calls to respond instead of waiting. That would be the only logical gain for your case as this RFC is not about parallelism. Amphp package uses fibers to do the same from what I know but you have to define the process switch logic.

Your case could be handled with curl multi init. A http call for each carrier. But that would involve booting the app for each call. If that is faster than the current way, you should try it. To avoid auth checks (if you are not already in a microservice) you could try also to replicate the Concurrency model from Laravel that would boot a new application for each background parallel command.

[EdmondDantes]

Assuming the computations are truly complex (although it’s hard for me to imagine what “complex” means here. Do they take more than 1 second of CPU time?), this problem is better solved using a thread pool.

If the computation does not take much time, it is better to use single-threaded coroutines, since no serialization code is needed. It is possible that after the RFC is accepted, access to threads and channels will become available, and such scenarios can be handled much more easily.

[2636011055]

you can see https://wiki.swoole.com/en/#/thread/thread
it is ‌the‌ swoole for php Thread

[xperia-query]

Node.js is single-threaded.
I wish PHP were faster than Node.js.

DB I/O time is a waste.

[marius-ciclistu]

Node js is full of vulneranilities.

[xperia-query]

Node js is full of vulneranilities.

Go has goroutines based on multithreading. If PHP were multithreading-based, it could potentially be as fast as Go ?

[marius-ciclistu]

No. Php is interpreted while go is compiled language.

[kynx]

Hey @EdmondDantes just read a large chunk of the the last (#\5?) discussion from the RFC. You are a man of passion and some patience 😄

You ask for examples of existing async solutions… two years ago I wrote a “job runner” that gets notifications from PubSub, spins up a Cloud Run job and polls it until completion. Yeah, Cloud Functions can do much the same, but there were, uh, reasons. It’s all IO. The only thing it has to do sync is respond as quickly as possible to PubSub saying “yeah got that”.

I did it in Swoole. One hell of a learning curve, but the result has amazed me: <10ms response times, thousands of concurrent jobs monitored off a single instance. And outside spikes it costs close to zero (we’re paying while HTTP requests are active, the polling happens out-of-band save a periodic keep-alive ping back to PubSub, so we’re basically leaching GCP cycles).

But, and of some relevance the discussions, this wasn’t some off-the-shelf code I dropped in that magically worked async. Every bit was written with coroutines, atomics, connection pools etc there from the start. And still the early days were segfaults all the way down. Though I’m a huge fan of what Swoole does, the API is minging.

And so… I want your RFC to finally succeed: PHP needs it. Keep up the struggle 🥊

[kitrio]

https://www.reddit.com/r/PHP/comments/1ppnwtf/simulating_%D1%81oncurrent_requests_how_we_achieved/

This article explains why developers say PHP needs asynchronous feature
Some comments suggest using Swoole, but they are concerned about BC.

[macropay-solutions]

The issue that we faced while researching based on this RFC for asynchronous, concurrency, parallelism, single threaded, multi threaded was that not all developers understand that for true parallelism the scope needs to be shared from one thread to another while for single threaded async/concurrent processing involving I/O, the scope does not need to be copied/shared.

[kynx]

@macropay-solutions the RFC covers implementing coroutines within a single process, yes. And look at the difficulty even that is having. One step at a time.

[marius-ciclistu]

@kynx maybe the I/O functionality suporting async like curl multi init would be a good first step forward. For example DB queries.

[albertcht]

Some real-world examples from projects I've actually worked on:

1. As an API Gateway
   When your app has multiple third-party APIs behind it that need to forward requests, and you need real-time responses from those third-party APIs to return as results.

2. Providing LLM-based request services
   Similar to the first scenario, especially in the past two years with the rapid development of AI, more and more systems integrate AI into their systems. For example: building a customer service system based on third-party LLMs, where a single request often takes 5-10+ seconds.

Both examples above clearly demonstrate situations where requesting resources from third-party APIs may require long I/O waits, and traditional PHP's blocking I/O cannot solve the problem at all - you can only rely on scaling machine resources to improve service concurrency.

[marius-ciclistu]

This RFC is about async/concurrency (single threaded) not about parallelism.

[albertcht]

My point is that curl_multi_* doesn't provide true async concurrency, while it can parallelize multiple HTTP requests within one execution context, the entire PHP worker is still blocked during those requests.

What we need (and what this RFC aims to provide) is the ability for a single worker to handle multiple USER requests concurrently by yielding control during I/O waits - something curl_multi_* cannot do.

[marius-ciclistu]

@EdmondDantes is that so?

[EdmondDantes]

curl_multi_init() is an official cURL API for event loop–based applications. It is, of course, used by TrueAsync and Swoole to mask cURL calls under the hood. cURL multi has no direct relation to parallelism.

One of the drawbacks of PHP’s strategy as a language is that PHP often pulls in things it doesn’t actually need as a high-level language. For example: cURL multi, low-level socket APIs, and similar features. This turns PHP into a hybrid that seems unable to decide whether it is a high-level language or assembly.

In other words, the existence of the curl_multi API in PHP is an unfortunate misunderstanding. :)

[marius-ciclistu]

I was refering to this RFC being single threaded without thread poll.

[marius-ciclistu]

This php parallel https://www.php.net/manual/en/book.parallel.php is interesting.
Too bad it is abandoned and not maintained. In theory it could be used for parallel mysql queries that have bindings (mysql_poll with MYSQL_ASYNC can be used for queries that don't have bindings).

Usecase: Eager load many relations on the model in Eloquent.

[EdmondDantes]

@pronskiy does it have some corner case? Can you use it just like curl_multi_init to write the results of a query in the same array without race issues?

Curl multi can only be used in a single thread, because the library itself is not thread-safe.

[marius-ciclistu]

Ok, but the question was about the parallel lib.

[EdmondDantes]

Ok, but the question was about the parallel lib.

Yes, that’s exactly what I mean.
The parallel library runs the function in another thread, so it’s not suitable for multiCurl.

[marius-ciclistu]

Let me rephrase. I want to improve the response times in maravel ecosystem (maravel-rest-wizard + Laravel, Maravelith, Lumen, Maravel) for lists that contain over 20-30 relations.

Curently I use mysqli_poll and MYSQLI_ASYNC when the bindings are empty via 2 connections and curl_multi_init for the rest via 2 calls if the remaining relations are above 8 for example.

This cuts the sql execution time but the actual eager loading of the data is still sync.

The issue is that making http calls implies booting the app for each request. If parallel could be used to return the same response as the http call does while receiving the sqls and their bindings + db connection credentials, the cost of http + boot + route selection could be removed.

[marius-ciclistu]

Now I see parallel ext requires ZTS which is slower. So dead end.

[StmuBa86]

i have CLI daemon workloads that are long-running and heavily I/O-bound. Today, I am forced to rely on pcntl_fork() and process-based concurrency to work around blocking I/O in PHP.

you can take any type of cli daemon as an example:
a daemon managing many devices via MQTT, combined with HTTP calls to vendor APIs and frequent database inserts and selects. This requires handling many concurrent connections, timers (heartbeats, retries), proper signal handling, ... etc.

Without native async and non-blocking socket/stream I/O in core, the only viable approach is spawning dozens or hundreds of forked PHP processes. This is inefficient, unnecessarily complex, and the main reason PHP is currently not viable for modern, I/O-heavy CLI daemons and background services.

A standardized async and non-blocking I/O foundation in PHP core would allow these workloads to be handled by a single or small number of PHP CLI processes, making PHP a realistic choice for worker daemons, schedulers, and queue consumers—without relying on userland event loops or external extensions.

[omegaalfa]

Dear EdmondDantes,
I have been following the development of the RFC "PHP True Async" and the discussions around it with great interest. The proposal to introduce native support for coroutines and the async/await model is, in my opinion, something that has the potential to revolutionize the development of long-running applications in PHP.
I would like to share a practical example of a task that would become significantly more elegant and efficient with the implementation of this RFC. The task in question is implementing progressive wait logic (exponential backoff) for asynchronous webhook and notification deliveries.

The Current Problem (Without Native Async):
In many scenarios, when a service needs to notify an external system (for example, an ERP, a payment service, or a third-party system) about an event (such as job completion, status update, etc.), it sends a webhook. If the receiving system fails to respond or returns an error (such as 429 Too Many Requests or a 5xx), a retry strategy must be implemented.
Currently, in pure PHP, the options to handle this involve:

Using delayed job queues: Sending the message to a queue (such as Redis Queue, RabbitMQ) and configuring the queue to retry after a certain time. If the wait time needs to increase exponentially after each failure, the configuration can become complex and, in some cases, requires a separate process to manage retry states.
Using sleep() in a dedicated worker: If we are talking about a CLI script that manages notifications, we can use sleep() to introduce the delay. However, this blocks the entire PHP worker, consuming valuable resources and limiting the ability to process other tasks simultaneously. An attacker could easily exploit this by flooding the server with requests that trigger long sleep() calls.
Relying on cron jobs for retries: A more rudimentary approach where a cron job periodically checks failed tasks and attempts to resend them. This adds latency and complexity in coordination.

How "PHP True Async" Would Solve This Problem:
With the proposed coroutines and async/await model, we could implement this logic much more cleanly and efficiently:

The PHP worker (or main coroutine) would not be blocked: Instead of using sleep(), we could use the suspend() or await() function with a timer. This would allow the coroutine to yield control back to the scheduler while waiting, freeing the worker to process other requests or tasks.
Retry logic intrinsic to the coroutine: The coroutine sending the webhook could manage the exponential backoff itself. If an error occurs, it simply "suspends" its execution for a calculated period and resumes after the time expires to retry.
Efficient resource management: In a stateful server scenario (such as one with coroutine-based architecture), the cost of keeping a coroutine suspended waiting for a timer is infinitesimally smaller than keeping an entire process or thread blocked.

Simplified (Conceptual) Code Example:

<?php

use function Async\spawn;
use function Async\await;
use function Async\suspend;
use Async\Coroutine;

// Fictional function to simulate sending a webhook and a possible failure
function sendWebhook(string $url, array $payload): void {
    echo "[INFO] Attempting to send webhook to: {$url}\n";

    // Simulates a failure 50% of the time
    if (rand(0, 1) === 0) {
        throw new \Exception("Failed to send webhook: Status 503 Service Unavailable");
    }

    echo "[SUCCESS] Webhook successfully sent to: {$url}\n";
    // Here, we would make a real HTTP request
    // For example: file_get_contents($url . '?' . http_build_query($payload));
}

// Function that manages sending webhooks with exponential backoff
function sendWebhookWithRetry(string $url, array $payload, int $maxRetries = 5): void {
    $retryCount = 0;
    $baseDelay = 1; // seconds

    while ($retryCount < $maxRetries) {
        try {
            sendWebhook($url, $payload);
            return; // Success, exit the function
        } catch (\Exception $e) {
            $retryCount++;
            echo "[WARN] Webhook failure (attempt {$retryCount}/{$maxRetries}): {$e->getMessage()}\n";

            if ($retryCount >= $maxRetries) {
                echo "[ERROR] Maximum retry attempts reached for: {$url}\n";
                // Here, you can record the final failure in a persistent log
                // or trigger a critical alert.
                return;
            }

            // Exponential backoff calculation: baseDelay * 2^(retryCount - 1)
            // E.g.: 1s, 2s, 4s, 8s, 16s
            $delay = $baseDelay * pow(2, $retryCount - 1);
            echo "[INFO] Waiting {$delay} seconds before the next attempt...\n";

            // Instead of sleep(), we use suspend() to yield to the scheduler
            // An awaitable timer could be created by a utility function
            // that returns a Completable which completes after a set duration.
            // For this example, we’ll simulate with a suspension loop.
            $startTime = microtime(true);
            while (microtime(true) - $startTime < $delay) {
                suspend(); // Yield control to other coroutines
            }
        }
    }
}

// Simulation of a main script that triggers multiple webhooks
$webhookWithRetryTasks = new Async\TaskGroup(captureResults: true);

spawn with $webhookWithRetryTasks sendWebhookWithRetry("https://erp.example.com/webhook", ["data" => "job_completed_1"]);
spawn with $webhookWithRetryTasks sendWebhookWithRetry("https://payments.example.com/webhook", ["data" => "payment_confirmed_2"]);
spawn with $webhookWithRetryTasks sendWebhookWithRetry("https://notifications.example.com/webhook", ["data" => "user_registered_3"]);

try {

  [$erp, $payments, $notifications] = await $webhookWithRetryTasks;
  
  return [
    'erp' => $erp,
    'payments' => $payments,
    'notifications' => $notifications,
  ];
} catch (\Exception $e) {
    logError("Webhook loading failed", $e);
    return ['error' => $e->getMessage()];
}

[marius-ciclistu]

Hi. Just a side note. Your logic fails if the process dies or its wait time for a job exceeds the visibility from SQS for example. I handle something similar for years now in php + delayed queues.

Still the async can be useful if implemented and used right.

[EdmondDantes]

Thank you very much for the post. This is indeed one of the most common real-life scenarios I encounter. Essentially, it’s a retry policy.

In terms of implementation:

1. sleep can be used, TrueAsync is aware of it.
2. delay() is even better, it throws a cancellation exception. This is convenient if coroutines are cancelled.

for ($retry = 1; $retry <= $maxRetries; $retry++) {
    try {
        sendWebhook($url, $payload);
        return;
    } catch (\Throwable $e) {
        echo "[WARN] Webhook failure (attempt {$retry}/{$maxRetries}): {$e->getMessage()}\n";

        // 1s, 2s, 4s, 8s, ...
        $delay = $baseDelay * (2 ** ($retry - 1));
        echo "[INFO] Waiting {$delay} seconds before the next attempt...\n";

        // Cancellation-safe delay
        Async\delay($delay);
    }
}

echo "[ERROR] Maximum retry attempts reached for: {$url}\n";
// persist failure / alert

[EdmondDantes]

Websocket.

WebSocket support makes no sense without asynchrony. This is the main reason why PHP doesn’t work with WebSockets.

[omegaalfa]

Completely agree.

WebSockets are fundamentally incompatible with PHP’s traditional blocking execution model. Without native async I/O and coroutine-based concurrency, every open WebSocket connection effectively ties up a worker, making the model unscalable by design.

This is exactly why WebSockets in PHP today are either:

• delegated to external services (Node.js, Go, Elixir),
• implemented via extensions like Swoole/React/Amp with custom runtimes,
• or avoided altogether in favor of polling.

With native async support in core, PHP could finally handle WebSockets as first-class citizens: a single process managing thousands of concurrent connections, yielding during I/O waits, handling timers, heartbeats, and message fan-out efficiently.

In that sense, WebSocket support is not a separate feature — it is a direct and practical consequence of having true asynchronous execution in PHP.

[omegaalfa]

One real-world scenario that hasn’t been discussed much yet is early cancellation on client disconnect.

Today, if a client closes the connection, PHP typically continues executing the request: outbound HTTP calls keep running, database queries complete, and timers expire — even though the result will never be delivered. This leads to unnecessary resource consumption and wasted I/O.

With coroutine-based async execution and cancellation, this changes fundamentally. Once the client disconnects, the coroutine can be cancelled, and all pending I/O operations can be aborted cooperatively, immediately releasing resources.

This is especially relevant in real-world scenarios like mobile networks, users navigating quickly between pages, and dashboards or streaming endpoints where clients frequently connect and disconnect.

To me, this is a strong example of how cancellation is not a “nice to have”, but a core requirement for PHP as a network-oriented language — and it fits naturally into the model described by this RFC.

[macropay-solutions]

True, but there are cases when you would want the php to finish even if the client closed the connection.

[omegaalfa]

I fully agree with my colleague @macropay-solutions on a crucial point: there are indeed scenarios where we want PHP to continue executing, even with the client disconnected. This is an important nuance worth exploring further.
My initial argument about early cancellation upon client disconnection is not intended to completely eliminate background execution. Quite the contrary, it's about giving the developer granular control to decide what to do in these situations.
Consider the following:

Long-running and independent tasks: Imagine an image processing system initiated by a user. If the user disconnects while the image is being resized, it's crucial that this task continues. It's independent of the client session and needs to be completed. The coroutine model with cancellation allows us to manage this. We can initiate an asynchronous task that, once started, operates independently of the original connection, and we can explicitly define that it should not be cancelled by the client's disconnection.

Guaranteeing critical operations: In some cases, even if the client disconnects, we need to be certain that an operation has been finalized. An example would be logging a security event, sending a critical error notification to a monitoring service, or completing a bank transaction where the client no longer needs to see the final result, but the operation itself needs to be completed for system integrity.

The core of my argument, and what I believe the RFC aims to address, is the automatic prevention of wasted resources when continued execution is not intended or beneficial. Currently, execution continues without the developer necessarily opting for it. The default behavior is "run to completion," which can be a significant problem at scale.
With coroutines and cancellation, the idea is that client disconnection becomes an event that can be handled. We can explicitly configure that a certain operation should be abandoned (cancelled), freeing up resources immediately, or that another operation should proceed to its natural completion, even without the client's presence.
In summary, @macropay-solutions, you've hit on an excellent point. Cancellation isn't about stopping everything indiscriminately, but about having the ability to intelligently decide which parts of the execution should be interrupted and which should continue, optimizing resource usage and the robustness of our PHP code in network scenarios. And this, in my opinion, is a fundamental advancement.

[Runnin4ik]

I’ve been following this RFC. Thank you for the monumental effort.

I want to share a real-world example of why this RFC is crucial not just for high-load scenarios, but for general-purpose library development. I am writing a Telegram client (MTProto) in PHP — ProtoBrick: https://github.com/Proto-Brick/php-mtproto-client/

MTProto is a complex stateful protocol: it requires a persistent TCP connection, encryption, and RPC calls. I am currently using Amphp v3.

Implementing such a client fully in standard PHP is problematic. At any given moment, the library must maintain at least five independent processes: a persistent Read Loop, session keep-alive ping timers, hundreds of individual timeout timers for RPC requests, background state persistence to disk, and update queue processing loops.

But even with current frameworks, we remain hostages to two problems that True Async would solve once and for all:

1. The "Fragile" Event Loop Problem

Even if I write perfect async code internally, the end user will break it. Classically: a developer receives a message in a bot, wants to pause, and writes sleep(5). Or executes a heavy synchronous database query via standard PDO.

In the current reality (Amp/React), this stops the entire process. My library stops sending ping packets and handling keep-alives; Telegram detects a timeout and drops the connection. The user experiences a script crash and complains about a "buggy lib."

Currently, to protect against this, we have to use workarounds:

• Process Separation: One process for the pure Event Loop (holding the connection), and a second worker for user code. Shuffling data via IPC/sockets is a huge overhead for a simple task.
• Static Analysis: Parsing user code to check for sleep() and other blocking functions to throw warnings. This is absurd.
• Documentation: Writing in bold caps in the README: "DO NOT USE SYNCHRONOUS FUNCTIONS!". But we know this isn't always read.

With True Async, that ill-fated sleep() would simply suspend the current coroutine. Pings and other update processing would continue working. This would make the ecosystem orders of magnitude friendlier and safer, especially for beginners.

2. State Management Hell (RPC) and "Function Coloring"

Implementing the RPC pattern ("sent request -> waiting for response with specific ID") currently requires manual micromanagement of timers and promises.

Furthermore, due to "function coloring," I am forced to duplicate all library methods: for every one of the 1000+ Telegram API methods, I have to generate a methodAsync() version and a synchronous method() wrapper for user convenience.

A. Current Async (Amp/React)

The logic is smeared: we need to manually cancel timers and clean the registry in every branch (both success and error), otherwise, we risk memory leaks or attempts to resolve a promise twice.

Pseudocode approximating reality:

class RpcClient {
    private array $pending = []; // [msg_id => ['def' => DeferredFuture, 'timer' => string]]

    /** @return Future<RpcResponse> */
    public function call(RpcRequest $req, float $timeout = 30): Future {
        $deferred = new DeferredFuture();
        $msgId = $req->getMsgId();

        // Manual creation of timeout timer
        $timerId = EventLoop::delay($timeout, function () use ($msgId) {
            if (isset($this->pending[$msgId])) {
                $this->pending[$msgId]['def']->error(new RuntimeException("Timeout"));
                unset($this->pending[$msgId]);
            }
        });

        $this->pending[$msgId] = ['def' => $deferred, 'timer' => $timerId];
        $this->transport->write($req->serialize());

        return $deferred->getFuture(); // The function gets "colored" (returns Future)
    }

    private function readLoop(): void {
        // Launched as a background task via Amp\async()
        while ($packet = $this->transport->read()) {
            $id = $packet->getMsgId();
            if ($entry = $this->pending[$id] ?? null) {
                EventLoop::cancel($entry['timer']); // Mandatory manual cleanup
                unset($this->pending[$id]);
                
                if ($packet->isError()) {
                    $entry['def']->error(new RpcErrorException(...));
                } else {
                    $entry['def']->complete($packet->getBody());
                }
                
            }
        }
    }
}

// User call, uses call() internally
$client->sendMessage(...);
$client->sendMessageAsync(...)->await();

B. True Async (RFC 1.7)

The logic gets rid of wrappers and manual state management. Micromanagement disappears: Async\timeout handles waiting at the engine level, and the finally block guarantees registry cleanup in one place. The API returns the result directly, not a Future wrapper. The entire lifecycle of an RPC call fits into one function, and API method duplication becomes unnecessary.

class RpcClient {
    private array $awaiting = []; // [msg_id => Completable]

    // Method returns result immediately or throws exception
    public function call(RpcRequest $req, int $timeoutSec = 30): RpcResponse {
        $msgId = $req->getMsgId();
        $res = new ResponseCompletable(); // Implements Completable
        $this->awaiting[$msgId] = $res;

        try {
            $this->transport->write($req->serialize());

            // Wait for response OR AwaitCancelledException
            return Async\await($res, Async\timeout($timeoutSec * 1000));
        } finally {
            unset($this->awaiting[$msgId]); // Centralized guaranteed cleanup
        }
    }

    private function readLoop(): void {
        Async\spawn(function() {
            while ($packet = $this->transport->read()) {
                $id = $packet->getMsgId();
                $completable = $this->awaiting[$id] ?? null;

                if ($packet->isError()) {
                    $completable?->fail(new RpcErrorException(...));
                } else {
                    $completable?->complete($packet->getBody());
                }
            }
        });
    }
}

$client->sendMessage();
// or in background
Async\spawn(fn() => $client->sendMessage(...));

---

I would also like to separately mention how I plan to use other True Async mechanisms:

Transitioning to TrueAsync and its Cancellable by design concept brings the risk of coroutine interruption at any suspension point. For MTProto, this is problematic: interrupting Sequence Number updates or session disk writes can violate protocol state machine logic and lead to desynchronization with the server.

Although the client is capable of self-recovery, I plan to use Async\protect as the main tool to guard these bottlenecks. This guarantees their integrity, while all other network I/O remains cancellable by default, allowing the client to be maximally responsive to system signals or timeouts.

---

Furthermore, I plan to implement Structured Concurrency via the Async\Scope mechanism. In the MTProto client, this solves the problem of "abandoned" coroutines: background tasks like readLoop, pingLoop, and periodic session saving will be rigidly tied to the scope hierarchy.

When stopping the client or closing a specific connection, I won't have to manually clean up timers and queues—it will be sufficient to cancel the corresponding Scope, and all child processes will terminate automatically and predictably.

I really hope this RFC passes!

[EdmondDantes]

This is a great post that clearly shows how theory interacts with practice. Thank you!

[gemini133]

back to years ago, I worked on an ecommerce project which allows customers to add their own images to the product.
a product has about 7 mockups.
the image composition process is complex (download, resize, rotate, affine transform etc,. heavy cpu bound tasks) and we were using libvips via php ext.
For user experience, we want to show previews to customers as soon as possible.
In the end, we fire 7 requests to our mockup server via javascript from frontend.
could it benefit from true async?

[EdmondDantes]

Yes, it can. This is an ideal case for combining a coroutine with a job running in a separate thread or process.

[EdmondDantes]

https://www.reddit.com/r/ProWordPress/comments/1qkzczj/needing_async_or_parallel_api_querying_behavior/

+1 case for wp

[marius-ciclistu]

While working on this segregation of relation definitions into closures, I realized a case when true async would mess things up.

The BelongsTo relation family needs a param of relation name. When not provided it is guessed through debug backtrace. I set a private static property to hold that name so I can read it when guessing and bypass debug backtrace.

If a relation executes an exists query inside its definition and the async worker switches scopes (while that query is executed), handling the next relation which executes another query, the static flag could be messed up.

[EdmondDantes]

I set a private static property to hold that name so I can read it when guessing and bypass debug backtrace.

Do you mean the case where DebugBackTrace is used as a context pattern?
So, the problem is not with TrueAsync itself, the task is being solved using a workaround.
For this to work reliably, the solution itself must also be reliable. However, on the other hand, if the call stack is synchronous, there will be no difference. But if it becomes asynchronous, the question arises why.

[marius-ciclistu]

No. Stack trace asyde, it impacts any logic that relies on the process being sync between the start of a try and its finally block (only fatal errors prevent the finally block from executing) when the context is switched in between the start of the try and its finally block.

Examples include the laravel eager loading, the data leak prevention I did a while ago (link above) and the avoidance of using debug backtrace via static variable that lead me to realize this scenario.

[EdmondDantes]

No. Stack trace asyde, it impacts any logic that relies on the process being sync between the start of a try and its finally block (only fatal errors prevent the finally block from executing) when the context is switched in between the start of the try and its finally block.

Examples include the laravel eager loading, the data leak prevention I did a while ago (link above) and the avoidance of using debug backtrace via static variable that lead me to realize this scenario.

Could you sketch a simple example?

[macropay-solutions]

// Order model
private static ?string $segregatedRelationNameBeingCalled = null;

public function getRelationResults(string $method): Model|Collection|null
{
    $previous = self::$segregatedRelationNameBeingCalled;

    try {
        self::$segregatedRelationNameBeingCalled = $method;
        $closure = $this->{$method}(...);

        return $closure->call($this)->getResults();// sql is placed here for the sake of this example, usually it should be after finally.
    } finally {
        self::$segregatedRelationNameBeingCalled = $previous;
    }
}



public function customer(): BelongsTo
{
    return $this->beongsTo(Customer::class);
}

public function deliveryNotes(): BelongsToMany
{
    return $this->belongsToMany(DeliveryNotes::class);
}

public function invoiceOrInvoices(): BelongsToMany
{
    if ($this->exists && $this->deliveryNotes()->count() > 1) {
        return $this->belongsToMany(Invoice::class, OrderInvoicePivot::class)->where(/*some condition*/);
    }

    return $this->belongsToMany(Invoice::class, OrderInvoicePivot::class);
}

// the last param of belongsTo and belongsToMany is the relation name which is guessed based on debug backtrace in  Laravel Eloquent
// and via debug backtrace AND the static property in Maravel Eloquent:

protected function guessBelongsToRelation()
{
    [$one, $two, $caller] = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 3);

    $relation = (string)($caller['function'] ?? ''); // Laravel returns this

   // Maravel logic for segregatedRelations

    if (
        ('' === $relation || \str_contains($relation, '{closure}'))
        && isset(static::$segregatedRelationNameBeingCalled)
    ) {
        return static::$segregatedRelationNameBeingCalled; 
    }

    return $relation;
}

// now the scenario
$model = Order::query()->firstOrFail();
$invoiceOrInvoices = $model->getRelationResults('invoiceOrInvoices');
$customer = $model->getRelationResults('customer');

This is what happens:

1. the static is set to invoiceOrInvoices
2. the invoiceOrInvoices method is called as closure
3. the deliveryNotes method is called
4. the guess returns deliveryNotes based on debug backtrace
5. the sql triggers for the count and it switches context (remember the static is invoiceOrInvoices
6. the static becomes customer
7. the customer method is called as closure
8. the guess returns 'customer'
9. the sql for retrieving the customer fires and switches context. static is still customer

we go back to 5.

• the sql count returned 2 for example
• belongsToMany method is called
• the guess returns {closure} based on backtrace so it looks at the static and returns customer instead of invoiceOrInvoices

It is a stupid example just for exemplifying the corner case.

This is to be taken into consideration because this RFC states (among other things) that:

• old sync code will work as it worked before
• sql query is or can be a context switcher

[marius-ciclistu]

Another corner case scenario is the strtok pointer which behaves like a global.

[kynx]

No expert on true-async, but from my use of Swoole I surmise static stuff doesn’t work in coroutines for precisely the reasons you outline. You are safest avoiding state of any kind (not a bad idea anyway).

I’m also only vaguely conversant with Laravel, but for some time have been meaning to check out how Octane handles this problem. What do they do?

[marius-ciclistu]

I never used octane and I hope I wll not have to. Share nothing is safe, no russian roulette desire from me...

While doing the segregated relation definition I realized that each closure captures its scope and if the cached in memory closures (macros included) are not bindTo null, they will keep a reference to the object avoiding its deletion by the garbage collector. I pin pointed this to Laravel here. Octane had and maybe still has its issues with memory from my knowledge.

[lucaswitch]

Nativephp is a project that ports php to Desktop/Mobile applications alongside with laravel ecossystem. It has everything that a standard web application would have. In a case where php would be the renderer is crucial to have true async to not slow down the UI when performing a IO bound op.

And native applications have a lot of IO bound operations like reading the db, sending notifications, grabbing os preferences, bluetooth, wifi, performing requests, battery.

Plus true async as it is, channels could work a lot a standard way to read OS state related stuff.

Plus in the future it could grow to a standard way to perform modern multithreading with php, with some kind of standard thread pools like we already have in kotlin.

I m so happy that this feature have a big chance to come to standard php. Can't wait to use in prod