Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129308
Precedence: list
MIME-Version: 1.0
Date: Wed, 19 Nov 2025 16:40:57 +0100
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
In-Reply-To: <CAMW7n8Ct-w-BqFGWWxU_2Q-M=_e2xiYUpMAZqXVJUTUBULO5MA@mail.gmail.com>
References: <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
 <21911eecbb08cd0845784e54b942e0da@bastelstu.be>
 <CAMW7n8Ct-w-BqFGWWxU_2Q-M=_e2xiYUpMAZqXVJUTUBULO5MA@mail.gmail.com>
Message-ID: <6b52b6c8a4c869d1f801f0a896a0f63a@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-11-19 16:19, schrieb Edmond Dantes:
>> I'm afraid to note that the proposed API is in violation of our policy 
>> regarding Throwables
> Thank you. It was fixed.

That is not quite right. The base exception should be 
`\Async\AsyncException`. I am also noticing that you changed the 
`DeadlockError` to `DeadlockException` which is a significant change 
from the previous proposal. The Error hierarchy is meant for problems 
that are not expected to be caught, because they cannot usefully be 
handled. The Exception hierarchy is something that should be caught.

Given that the RFC says (highlighting mine):

> This condition is called a Deadlock, and it represents a **serious 
> logical error**.

I believe it should be a `DeadlockError` like it originally proposed. 
That one should then extend `\Async\AsyncError` and similarly 
`\Async\AsyncError` should extend `\Error.

Similarly for `CancellationError`. It should extend `\Async\AsyncError`. 
I'm seeing the comment “Does not extend Exception to avoid accidental 
suppression” which makes sense to me, but the Error hierarchy 
specifically isn't an Exception. And folks catching `\Throwable` will 
catch `CancellationError` as well, so I don't see a reason why it should 
be treated differently in this regard.

------------

Looking at the stub more carefully, I'm also seeing that 
`\Async\gracefulShutdown()` should be `\Async\graceful_shutdown()` 
instead (and similarly for `currentCoroutine()` -> `current_coroutine()` 
and `getCoroutines()` -> `get_coroutines()`). This is something that I 
could have caught earlier and I'm sorry that I did not. However since 
changes to the RFC will still be required (which means that the vote 
will need to be cancelled), it probably makes sense to fix that as well.

Best regards
Tim Düsterhus