Download the PHP package sof3/await-generator without Composer
On this page you can find all versions of the php package sof3/await-generator. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download sof3/await-generator
More information about sof3/await-generator
Files in sof3/await-generator
Package await-generator
Short Description Use async/await in PHP using generators
License apache-2.0
Informations about the package await-generator
Eng | 简
await-generator
A library to use async/await pattern in PHP.
Documentation
Read the await-generator tutorial for an introduction from generators and traditional async callbacks to await-generator.
Why await-generator?
Traditional async programming requires callbacks, which leads to spaghetti code known as "callback hell":
Click to reveal example callback hell
With await-generator, this is simplified into:
Can I maintain backward compatibility?
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:
Or if you want to handle errors too:
You can continue to call functions implemented as callback style
using the Await::promise
method (similar to new Promise
in JS):
Why not await-generator
await-generator has a few common pitfalls:
- Forgetting to
yield from
aGenerator<void>
method will end up doing nothing. - If you delete all
yield
s from a function, it automatically becomes a non-generator function thanks to PHP magic. This issue can be mitigated by always adding: Generator
to the function signature. finally
blocks 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.
But what about fibers?
This might be a subjective comment, but I do not prefer fibers for a few reasons:
Explicit suspension in type signature
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).
Concurrent states
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.
Trapping 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.
All versions of await-generator with dependencies
ext-bcmath Version *