Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126541
Feedback-ID: id5114917:Fastmail
Message-ID: <c1b1295e-a4c7-434f-8881-2d01a790fd83@rwec.co.uk>
Date: Sat, 1 Mar 2025 17:20:30 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC
To: internals@lists.php.net
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 01/03/2025 09:11, Edmond Dantes wrote:
>
> Good day, everyone. I hope you're doing well.
>
> I’d like to introduce a draft version of the RFC for the True Async 
> component.
>
> https://wiki.php.net/rfc/true_async
>

My reaction to this can be summed up as "this is huge!" By that I mean 
multiple things...

First: PHP having native async support would be a huge step forward for 
the language. It's really exciting to see how this proposal develops.

Second: it's clear you've put a huge amount of work into this, so a huge 
thank you for that, and I hope it is rewarded.

Third: this is a huge proposal to digest. I wonder if there are ways it 
can be split into smaller pieces, so that we don't overlook details in 
one part because our focus is drawn to another. That might mean 
releasing a partial implementation this year, and more features next 
year; or it might just mean discussing and merging some core pieces 
first, then immediately following up with a series of feature RFCs, all 
targeting the same release.

Fourth: design decisions here will have a huge impact on the language 
for years to come. We should spend plenty of time looking at experience 
from elsewhere - other languages, and existing third-party async 
implementations for PHP. This is closely related to the previous point, 
since expanding the current RFC with comparisons for every decision 
would make it impractically long.

Fifth: this is a huge amount of new code - GitHub says 24 thousand lines 
of added code, although some of that is tests and documentation (which 
is great to see included!) We need to make sure there are enough people 
who understand the implementation to maintain that. Maybe we can try to 
tempt some of the core contributors to existing third-party libraries to 
spend some of their time on php-src instead.


I realise I haven't actually given any concrete feedback on the proposal 
- I don't have any experience with other async implementations, and 
don't fully understand the concepts involved, so don't feel qualified to 
comment on the high-level design questions. I might have opinions on 
smaller design details (random example: RESOLVE, CANCEL, and TIMEOUT 
should be cases on an enum, not int constants) but see point 4: there's 
just too much here to discuss in that level of detail, and there are 
top-level decisions which should be our focus first.

To re-iterate: this is really exciting, and thanks for getting it to 
this stage!

-- 
Rowan Tommins
[IMSoP]