>> Crippling async PHP with async blocks just because some libraries aren't
>>ready for concurrency now, means crippling the future of async php.
>>
> How can calling a single function have such a destructive impact on the
> future of PHP?
Very simple: to make an analogy, it's like saying PHP should have an io {}
block, that makes sure all file resources opened within (even internally, 10
stack levels deep into 3 libraries, whose instances are all used after the io
{} block) are closed when exiting.
The async {} block is a footgun that tries to meddle with what must be an
internal implementation detail of the libraries you're using.
Even if they were optional, their presence in the language could lead library
developers to reduce concurrency in order to allow calls from async blocks,
(i.e. don't spawn any background fiber in a method call because it might be
called from an async {} block) which is what I meant by crippling async PHP.
If the async {} block were to ignore *referenced* spawned fiber handles, it
would still be just as bad: sometimes one really just needs to spawn a
background fiber to do a one-off background task, without caring about the
result.
I.e. the spawned logic may also contain a catch (\Throwable) block with error
handling, making collection of references into an array to awaitAll in
__destruct (just because someone might invoke the code from an async {} block!)
pointless and an overcomplication.
Amphp's approach of an event loop exception handler is, I believe, the perfect
uncaught exception handling solution.
(Also note that amphp also provides an escape hatch even for the exception
handler: a Future::ignore() method that prevents uncaught and non-awaited
exceptions from bubbling out into the exception handler).
Regards,
Daniil Gentili.
