On Sat, Mar 1, 2025, at 18:20, Rowan Tommins [IMSoP] wrote: > 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] >
I second this, and as a long time user of amphp, go, and C#, I’d be coming into it with a specific mindset. My only thing so far is that it appears the scheduler cannot be replaced; at least, easily. I don’t know if we would do so over on FrankenPHP, but it would be interesting to replace the scheduler with something that utilized go-routines for true multi-threading. Whether that works or not, is a whole different can of worms. I’m compiling a deeper review, but that speaks more to the implementation than the spec. — Rob
