> Offering this tool to userland is a major footgun that will either backfire
> spectacularly (breaking existing and new async libraries by endlessly
> awaiting upon background fibers when exiting an async {} block haphazardly
> used by a newbie, or even worse force library developers to reduce
> concurrency, killing async PHP just because users can use async {} blocks),
> or simply not get used at all (because the main SAPI usecase listed
> explicitly does NOT need purity).
Some extra points:
1) The naming of "async {}" is also very misleading, as it does the opposite of
making things async, if anything it should be called "wait_all {}"
2) Again, what are waiting for? A fiber spawned by a library we called 10
levels deep in the stack, that exits only when the container object is
destroyed (outside of the wait_all block, thus causing an endless hang)? No one
should care or be able to control what must remain an internal implementation
detail of invoked libraries, adding a wait_all block will only break stuff.
3) If we did want to wait for all fibers spawned by a method call, nothing is
preventing the caller from returning an array of futures for spawned fibers
that we can await.
The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of async
libraries, because the only feature it offers (that isn't already offered by
awaitAll) is one that controls internal implementation details of libraries
invoked within the block.
Libraries can full well handle cleanup of fibers in __destruct by themselves,
without a wait_all block forcing them to reduce concurrency whenever the caller
pleases.
It is, imo, a MAJOR FOOTGUN, and should not be even considered for
implementation.
Regards,
Daniil Gentili.
