Re: PSR-14 for Promises and Event Loop

Skip to first unread message

Larry Garfield

May 7, 2021, 10:05:06 AMMay 7
On Thu, May 6, 2021, at 4:06 PM, Italo Baeza Cabrera wrote:
> With the former inclusion of PHP Fibers in 8.1, it's widely known that
> next async frameworks like ReactPHP and Amp will start using PHP Fibers
> internally, while extensions like Swoole and
> While both of these frameworks are compatible, there is no guaranteed
> interoperability between async libraries.
> Seems that the common offering from these libraries are Event Loops
> (run tasks until error or no task is left) and Promises (execute now,
> wait for value later) that represent the state of a callback sent to
> the Event Loop where its sent.
> I humbly think that an hypothetical PSR-21 would allow interoperability
> by abstraction, at least, once Fibers are published at the end of the
> year.

I have spoken to Aaron P (author of the Fibers RFC and Amp) extensively on this topic. The current plan is that Amp and React will co-develop a common loop and promise library that both end up using. That will effectively make it the de facto standard in the PHP ecosystem anyway. They would then both build different convenience APIs on top of the core plumbing.

I've suggested several times that FIG is happy to help as part of the standards process, but they seem comfortable doing their own thing independently. We're definitely happy to have such standards, but it has to be driven by the domain experts in that area for it to have any value, and so far the domain experts seem happy to collaborate independently of FIG.

--Larry Garfield

Italo Baeza Cabrera

May 7, 2021, 9:21:19 PMMay 7
to PHP Framework Interoperability Group
I understand. Seems that, at the end of the day, time will tell if their "way to standardize async" is good enough for the community to be widely used, specially on the stability side.

I don't think it would be harm to require in the future a `php-async/loop` and `php-async/promise` packages abstractions so a developer can choose how it wants to run them on. It just that, without FIG backing, these libraries will have to deal with promoting the common interface themselves.
Reply all
Reply to author
0 new messages