Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126543
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 01 Mar 2025 19:44:01 +0100
To: internals@lists.php.net
Message-ID: <c0db0315-e99f-4441-bcc3-dc5867d27542@app.fastmail.com>
In-Reply-To: <c1b1295e-a4c7-434f-8881-2d01a790fd83@rwec.co.uk>
References: 
 <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <c1b1295e-a4c7-434f-8881-2d01a790fd83@rwec.co.uk>
Subject: Re: [PHP-DEV] PHP True Async RFC
Content-Type: multipart/alternative;
 boundary=a23052fa6ac0438397adc11056bff9c6
From: rob@bottled.codes ("Rob Landers")

--a23052fa6ac0438397adc11056bff9c6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



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=E2=80=99d like to introduce a draft version of the RFC for the Tru=
e Async=20
> > component.
> >
> > https://wiki.php.net/rfc/true_async
> >
>=20
> My reaction to this can be summed up as "this is huge!" By that I mean=20
> multiple things...
>=20
> First: PHP having native async support would be a huge step forward fo=
r=20
> the language. It's really exciting to see how this proposal develops.
>=20
> Second: it's clear you've put a huge amount of work into this, so a hu=
ge=20
> thank you for that, and I hope it is rewarded.
>=20
> Third: this is a huge proposal to digest. I wonder if there are ways i=
t=20
> can be split into smaller pieces, so that we don't overlook details in=20
> one part because our focus is drawn to another. That might mean=20
> releasing a partial implementation this year, and more features next=20
> year; or it might just mean discussing and merging some core pieces=20
> first, then immediately following up with a series of feature RFCs, al=
l=20
> targeting the same release.
>=20
> Fourth: design decisions here will have a huge impact on the language=20
> for years to come. We should spend plenty of time looking at experienc=
e=20
> from elsewhere - other languages, and existing third-party async=20
> implementations for PHP. This is closely related to the previous point=
,=20
> since expanding the current RFC with comparisons for every decision=20
> would make it impractically long.
>=20
> Fifth: this is a huge amount of new code - GitHub says 24 thousand lin=
es=20
> of added code, although some of that is tests and documentation (which=20
> is great to see included!) We need to make sure there are enough peopl=
e=20
> who understand the implementation to maintain that. Maybe we can try t=
o=20
> tempt some of the core contributors to existing third-party libraries =
to=20
> spend some of their time on php-src instead.
>=20
>=20
> I realise I haven't actually given any concrete feedback on the propos=
al=20
> - I don't have any experience with other async implementations, and=20
> don't fully understand the concepts involved, so don't feel qualified =
to=20
> comment on the high-level design questions. I might have opinions on=20
> smaller design details (random example: RESOLVE, CANCEL, and TIMEOUT=20
> should be cases on an enum, not int constants) but see point 4: there'=
s=20
> just too much here to discuss in that level of detail, and there are=20
> top-level decisions which should be our focus first.
>=20
> To re-iterate: this is really exciting, and thanks for getting it to=20
> this stage!
>=20
> --=20
> Rowan Tommins
> [IMSoP]
>=20

I second this, and as a long time user of amphp, go, and C#, I=E2=80=99d=
 be coming into it with a specific mindset.=20

My only thing so far is that it appears the scheduler cannot be replaced=
; at least, easily. I don=E2=80=99t know if we would do so over on Frank=
enPHP, but it would be interesting to replace the scheduler with somethi=
ng that utilized go-routines for true multi-threading. Whether that work=
s or not, is a whole different can of worms.

I=E2=80=99m compiling a deeper review, but that speaks more to the imple=
mentation than the spec.=20

=E2=80=94 Rob
--a23052fa6ac0438397adc11056bff9c6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Sat, Mar 1, 2025, at 18:20, Rowan Tommins [IMSoP] wrot=
e:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 01/03=
/2025 09:11, Edmond Dantes wrote:<br></div><div>&gt;<br></div><div>&gt; =
Good day, everyone. I hope you're doing well.<br></div><div>&gt;<br></di=
v><div>&gt; I=E2=80=99d like to introduce a draft version of the RFC for=
 the True Async&nbsp;<br></div><div>&gt; component.<br></div><div>&gt;<b=
r></div><div>&gt;&nbsp;<a href=3D"https://wiki.php.net/rfc/true_async">h=
ttps://wiki.php.net/rfc/true_async</a><br></div><div>&gt;<br></div><div>=
<br></div><div>My reaction to this can be summed up as "this is huge!" B=
y that I mean&nbsp;<br></div><div>multiple things...<br></div><div><br><=
/div><div>First: PHP having native async support would be a huge step fo=
rward for&nbsp;<br></div><div>the language. It's really exciting to see =
how this proposal develops.<br></div><div><br></div><div>Second: it's cl=
ear you've put a huge amount of work into this, so a huge&nbsp;<br></div=
><div>thank you for that, and I hope it is rewarded.<br></div><div><br><=
/div><div>Third: this is a huge proposal to digest. I wonder if there ar=
e ways it&nbsp;<br></div><div>can be split into smaller pieces, so that =
we don't overlook details in&nbsp;<br></div><div>one part because our fo=
cus is drawn to another. That might mean&nbsp;<br></div><div>releasing a=
 partial implementation this year, and more features next&nbsp;<br></div=
><div>year; or it might just mean discussing and merging some core piece=
s&nbsp;<br></div><div>first, then immediately following up with a series=
 of feature RFCs, all&nbsp;<br></div><div>targeting the same release.<br=
></div><div><br></div><div>Fourth: design decisions here will have a hug=
e impact on the language&nbsp;<br></div><div>for years to come. We shoul=
d spend plenty of time looking at experience&nbsp;<br></div><div>from el=
sewhere - other languages, and existing third-party async&nbsp;<br></div=
><div>implementations for PHP. This is closely related to the previous p=
oint,&nbsp;<br></div><div>since expanding the current RFC with compariso=
ns for every decision&nbsp;<br></div><div>would make it impractically lo=
ng.<br></div><div><br></div><div>Fifth: this is a huge amount of new cod=
e - GitHub says 24 thousand lines&nbsp;<br></div><div>of added code, alt=
hough some of that is tests and documentation (which&nbsp;<br></div><div=
>is great to see included!) We need to make sure there are enough people=
&nbsp;<br></div><div>who understand the implementation to maintain that.=
 Maybe we can try to&nbsp;<br></div><div>tempt some of the core contribu=
tors to existing third-party libraries to&nbsp;<br></div><div>spend some=
 of their time on php-src instead.<br></div><div><br></div><div><br></di=
v><div>I realise I haven't actually given any concrete feedback on the p=
roposal&nbsp;<br></div><div>- I don't have any experience with other asy=
nc implementations, and&nbsp;<br></div><div>don't fully understand the c=
oncepts involved, so don't feel qualified to&nbsp;<br></div><div>comment=
 on the high-level design questions. I might have opinions on&nbsp;<br><=
/div><div>smaller design details (random example: RESOLVE, CANCEL, and T=
IMEOUT&nbsp;<br></div><div>should be cases on an enum, not int constants=
) but see point 4: there's&nbsp;<br></div><div>just too much here to dis=
cuss in that level of detail, and there are&nbsp;<br></div><div>top-leve=
l decisions which should be our focus first.<br></div><div><br></div><di=
v>To re-iterate: this is really exciting, and thanks for getting it to&n=
bsp;<br></div><div>this stage!<br></div><div><br></div><div>--&nbsp;<br>=
</div><div>Rowan Tommins<br></div><div>[IMSoP]<br></div><div><br></div><=
/blockquote><div><br></div><div>I second this, and as a long time user o=
f amphp, go, and C#, I=E2=80=99d be coming into it with a specific minds=
et.&nbsp;<br></div><div><br></div><div>My only thing so far is that it a=
ppears the scheduler cannot be replaced; at least, easily. I don=E2=80=99=
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 t=
rue multi-threading. Whether that works or not, is a whole different can=
 of worms.<br></div><div><br></div><div>I=E2=80=99m compiling a deeper r=
eview, but that speaks more to the implementation than the spec.&nbsp;</=
div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></bod=
y></html>
--a23052fa6ac0438397adc11056bff9c6--