PHP True Async
Async use cases #9
Replies: 20 comments 52 replies
|
IMO this is a given (otherwise we wouldn't even be having this discussion), but since it wasn't spelled out, concurrency allows for:
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. |
This is if the async would not be restricted to single thread(worker). See related question about this. |
|
Today I ran into a task where async would be useful. 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. |
|
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. |
|
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... |
Yes, this is one of the typical scenarios that PHP is currently missing. |
Of course this would be a problem, which is why I’m saying that PHP cannot handle such scenarios at all. |
|
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:
Here's a simplified example: https://github.com/Gemorroj/parallel-nonserializable/blob/master/src/Test.php 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. |
|
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. |
|
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. |
|
you can see https://wiki.swoole.com/en/#/thread/thread |
|
Node.js is single-threaded. DB I/O time is a waste. |
|
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 ? |
|
No. Php is interpreted while go is compiled language. |
|
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 🥊 |
|
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 |
|
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. |
|
@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. |
|
@kynx maybe the I/O functionality suporting async like curl multi init would be a good first step forward. For example DB queries. |
|
Some real-world examples from projects I've actually worked on:
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. |
|
This RFC is about async/concurrency (single threaded) not about parallelism. |
|
My point is that 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 |
|
@EdmondDantes is that so? |
|
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. :) |
|
I was refering to this RFC being single threaded without thread poll. |
|
This php parallel https://www.php.net/manual/en/book.parallel.php is interesting. Usecase: Eager load many relations on the model in Eloquent. |
Curl multi can only be used in a single thread, because the library itself is not thread-safe. |
|
Ok, but the question was about the parallel lib. |
Yes, that’s exactly what I mean. |
|
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. |
|
Now I see parallel ext requires ZTS which is slower. So dead end. |
|
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: 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. |
|
Dear EdmondDantes, The Current Problem (Without Native Async): 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. How "PHP True Async" Would Solve This Problem: 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. 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()];
} |
|
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. |
|
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:
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 |
|
Websocket. WebSocket support makes no sense without asynchrony. This is the main reason why PHP doesn’t work with WebSockets. |
|
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:
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. |
|
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. |
|
True, but there are cases when you would want the php to finish even if the client closed the connection. |
|
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. 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. |
|
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 ProblemEven 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 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:
With True Async, that ill-fated 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 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: 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! |
|
This is a great post that clearly shows how theory interacts with practice. Thank you! |
|
back to years ago, I worked on an ecommerce project which allows customers to add their own images to the product. |
|
Yes, it can. This is an ideal case for combining a coroutine with a job running in a separate thread or process. |
|
+1 case for wp |
|
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. |
Do you mean the case where DebugBackTrace is used as a context pattern? |
|
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? |
// 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:
we go back to 5.
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:
|
|
Another corner case scenario is the strtok pointer which behaves like a global. |
|
No expert on 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? |
|
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. |
|
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 |
|
Hello. I've read over the specification again this afternoon while thinking on a long running problem in PHP - the inability to alias libaries. This creates a problem for very large applications which support plug ins from 3rd party vendors. WordPress is the most significant of these - and as a result WP has not adopted composer in any meaningful way. Meanwhile, Drupal has adopted it, but all extensions have to be kept relatively current so, again, they use the same libraries. The documentation on coroutines isn't clear, but how is autoloading handled in a coroutine? Does it use the same symbol table and variables? The answer I hope for is 'no.' because in that event, plugins and extensions can optionally be loaded as coroutines allowing them to install whatever version of a library they need. Another use case is the very way large CMS applications work. They have to go through several hundred lines to reach a ready state, then they consider the request, spit out a response and terminate. This is wasteful. it would be nice if a process could fetch a worker from a long running process which could fulfill the request. The worker would already be configured and set up by that process. Most of the use cases I've read in this discussion have been on the effects of more cutting edge applications. I'm hoping these ideas on how this might improve more traditional PHP applications help move things forward. Hoping to see this become part of core for PHP 9. It's the sort of sea change that justifies major version number changes. |
|
Hello. I'd be happy to answer questions. What you're looking at are stackful coroutines that can be suspended at any In essence, it's similar to Node.js, but without colored functions. A typical use case: Let's say I already have a module that sends logs over HTTP, and I don't
My approach is: spawn(my_function(...), ...args); // and I don't change anything else. Here, I'm telling PHP to execute existing code in a separate coroutine that As for module autoloading, coroutines do not affect it in any way. From a The main benefit of coroutines is that they allow part of the application We've already conducted some experiments with Laravel and Symfony, and I think an asynchronous backend can gain around 10–30% in throughput. The P.S. The current implementation also supports creating PHP threads. In that |
Uh oh!
There was an error while loading. Please reload this page.
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!
All reactions