PHP 2^3

Hi Niklas,

Hey Dmitry,

hi Aaron,

2. Better support long-running, async-based, microservices-focused execution model. It's probably no secret that one of the key reasons Node is gaining popularity is because it can handle a huge number of concurrent connections issuing relatively lightweight requests very efficiently - which is a good match for modern microservices based architectures. There are already several projects available for PHP that aim to provide similar functionality - most notably ReactPHP and more recently Swoole.
   The main thing that is missing is that most of PHP's IO doesn't support async execution. What I think we should do is add as much support for async IO as possible across the various extensions and streams - so that using something like Swoole would become practical for more use cases. More specifically - the goal would be to provide extension authors with mechanisms that they can use to make their extensions/functions optionally asynchronous, without having to tackle the job entirely on their own. While we've done some research into this area, it requires a lot more research - but I'm cautiously optimistic that it can be done. We would potentially want to use libuv for this task, and potentially rewrite or otherwise refactor parts of the PHP streams system.

Regarding async, are you referring to the Fiber extension? In my opinion, fibers would be the best approach for async in PHP. After using async/await in other languages, it doesn't offer a significant gain over what's already possible in PHP with generator-based coroutines in Amp. Using the fiber extension and a green-thread library that resumes fibers based on promise resolution [1], we've been able to write async code without the need for yield or await [2], with async functions having proper return types (i.e. not promise, but the type the promise would resolve to). Joel Wurtz has also put together a PoC of using Doctrine asynchronously using the fiber extension and Amp [3].

Febers/couroutines is one of the goals.
Another possible goal — event-loop primitives for internal extensions (e.g. async DB queries)
I think, we don't need async/await keywords or promises implementation in core
Anyway, as an expert in async PHP, you should tell us, what you really need from the PHP core...
I would be glad to hear your oppinion.

Thanks. Dmitry.

Fibers are the major feature we're looking forward to, because it
allows async I/O in places that do not account for async, e.g. also
re-using interfaces designed for sync applications. Apart from that,
we want to avoid the boilerplate we currently have to write, i.e.
Amp\call wrapping a generator function.

We already have ext/fiber proposal and additioal branch implementing stack-full fibers.
I think, we'll build fibers in the PHP core reusing this work, keeping the proposed API and behavior.

We think that a methodless "Promise" / "Awaitable" type + fibers
implemented with keywords are the preferred way over the current Fiber
draft in the long run.

This is too abstract.
What keywords do you like for fibers and why do we need them?
Why do we need Promise/Awaitable in the core?
If you have concrete solution (just API), lets discuss it in separate email thread.

Fibers allow for transparent async I/O, which means we could maybe
transparently upgrade file_get_contents and others to use async I/O in
future versions, but something like that obviously needs an event-loop
in core.

May be yes, may be not. Event-loop may be implemented in PHP, but perform integration with internal functions, through special interface (e.g. allow internal function to post compltion events into the event queue). Anyway, there is no any formed plan about event-loop in core. I hope, the experience of AMP team, would help us to make good decision. And I count on Bob, regarding implementation.

Thanks. Dmitry.

That said, it's definitely something we want to push to PHP 8, but
nothing that has to be discussed in too much detail in this thread.

Regards, Niklas