A library to use async/await pattern in PHP.
Read the await-generator tutorial for an introduction from generators and traditional async callbacks to await-generator.
Traditional async programming requires callbacks, which leads to spaghetti code known as "callback hell":
Click to reveal example callback hell
load_data(function($data) {
$init = count($data) === 0 ? init_data(...) : fn($then) => $then($data);
$init(function($data) {
$output = [];
foreach($data as $k => $datum) {
processData($datum, function($result) use(&$output, $data) {
$output[$k] = $result;
if(count($output) === count($data)) {
createQueries($output, function($queries) {
$run = function($i) use($queries, &$run) {
runQuery($queries[$i], function() use($i, $queries, $run) {
if($i === count($queries)) {
$done = false;
commitBatch(function() use(&$done) {
if(!$done) {
$done = true;
echo "Done!\n";
}
});
onUserClose(function() use(&$done) {
if(!$done) {
$done = true;
echo "User closed!\n";
}
});
onTimeout(function() use(&$done) {
if(!$done) {
$done = true;
echo "Timeout!\n";
}
});
} else {
$run($i + 1);
}
});
};
});
}
});
}
});
});$data = yield from load_data();
if(count($data) === 0) $data = yield from init_data();
$output = yield from Await::all(array_map(fn($datum) => processData($datum), $data));
$queries = yield from createQueries($output);
foreach($queries as $query) yield from runQuery($query);
[$which, ] = yield from Await::race([
0 => commitBatch(),
1 => onUserClose(),
2 => onTimeout(),
])
echo match($which) {
0 => "Done!\n",
1 => "User closed!\n",
2 => "Timeout!\n",
};Yes, await-generator does not impose any restrictions on your existing API. You can wrap all await-generator calls as internal implementation detail, although you are strongly encouraged to expose the generator functions directly.
await-generator starts an await context with the Await::f2c method,
with which you can adapt into the usual callback syntax:
function oldApi($args, Closure $onSuccess) {
Await::f2c(fn() => $onSuccess(yield from newApi($args)));
}Or if you want to handle errors too:
function newApi($args, Closure $onSuccess, Closure $onError) {
Await::f2c(function() use($onSuccess, $onError) {
try {
$onSuccess(yield from newApi($args));
} catch(Exception $ex) {
$onError($ex);
}
});
}You can continue to call functions implemented as callback style
using the Await::promise method (similar to new Promise in JS):
yield from Await::promise(fn($resolve, $reject) => oldFunction($args, $resolve, $reject));await-generator has a few common pitfalls:
- Forgetting to
yield fromaGenerator<void>method will end up doing nothing. - If you delete all
yields from a function, it automatically becomes a non-generator function thanks to PHP magic. This issue can be mitigated by always adding: Generatorto the function signature. finallyblocks may never get executed if an async function never resolves (e.g.Await::promise(fn($resolve) => null)).
While these pitfalls cause some trouble, await-generator style is still much less bug-prone than a callback hell.
This might be a subjective comment, but I do not prefer fibers for a few reasons:
For example, it is easy to tell from the type signature that
$channel->send($value): Generator<void> suspends until the value is sent
and $channel->sendBuffered($value): void
is a non-suspending method that returns immediately.
Type signatures are often self-explanatory.
Of course, users could call sleep() anyway,
but it is quite obvious to everyone that sleep() blocks the whole runtime
(if they didn't already know, they will find out when the whole world stops).
When a function suspends, many other things can happen. Indeed, calling a function allows the implementation to call any other functions which could modify your states anyway, but a sane, genuine implementation of e.g. an HTTP request wouldn't call functions that modify the private states of your library. But this assumption does not hold with fibers because the fiber is preempted and other fibers can still modify the private states. This means you have to check for possible changes in private properties every time you call any function that might be suspending.
On the other hand, using explicit await, it is obvious where exactly the suspension points are, and you only need to check for state mutations at the known suspension points.
await-generator provides a feature called "trapping", which allows users to add pre-suspend and pre-resume hooks to a generator. This is simply achieved by adding an adapter to the generator, and does not even require explicit support from the await-generator runtime. This is currently not possible with fibers.
![dependabot-preview[bot] avatar](https://avatars.githubusercontent.com/in/2141?v=4 "dependabot-preview[bot]")
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent