Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129249
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <CAEKnhAGJhR-EK_tjOBC78HUyiL0m_vJ-_toJgLdT8LLx+hREig@mail.gmail.com>
 <CAMW7n8CC8sq8hs2gLsDcr-78GehzHk+cAMR=pRsL9gim3=ovbw@mail.gmail.com>
 <CAEKnhAEoBdU-LpoXAGpAT0VNiphLWEfWqsJ6L-1NoQ0m0eYzTw@mail.gmail.com>
 <CAMW7n8AAf0Cn04c_xNmw6oV8fka3bh1Qgs1rKM4N+4kDYHUmGA@mail.gmail.com>
 <CAEKnhAHCG5KP3y2Y9njHRZPSscU=_+mAm-Krvxc33K-kptsxEA@mail.gmail.com> <CAMW7n8BTV07f3YFF8yEy0N_ZCV9c9hZ3f=GUEd0HegqcLdXzmQ@mail.gmail.com>
In-Reply-To: <CAMW7n8BTV07f3YFF8yEy0N_ZCV9c9hZ3f=GUEd0HegqcLdXzmQ@mail.gmail.com>
Date: Sat, 15 Nov 2025 23:24:26 +0100
Message-ID: <CAEKnhAH_F_=68wjYT_kU2WHkRMqJomYAV5AWueEi5-_KXj+xpw@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP True Async RFC Stage 5
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: php internals <internals@lists.php.net>, Larry Garfield <larry@garfieldtech.com>
Content-Type: multipart/alternative; boundary="0000000000005b19120643a99449"
From: bukka@php.net (Jakub Zelenka)

--0000000000005b19120643a99449
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 15, 2025 at 11:03=E2=80=AFPM Edmond Dantes <edmond.ht@gmail.com=
> wrote:

> Hello
>
> > It's 1.6k lines so it might help a little bit
> Yeah :)
>
> > Why do you need reactor for this specific part of proposal? The thing i=
s
> that there shouldn't be any IO so you reduce scheduler code as well and
> make it simpler and more reviewable.
>
> So you are suggesting removing all I/O from the RFC. On the one hand,
> that sounds appealing. It immediately eliminates a bunch of tests. But
> there is a trap we could all fall into.
> By separating the reactor and the scheduler, as well as the rules of
> how they work together, we might accidentally introduce an error into
> the document simply because the documents would be split.
> (interface drift)
>

I don't see it that way. You have already implementation showing that this
is workable for the proposed user interface so it's just addition into
that. I'm not sure how it could even impact user interface that is being
proposed? If you are talking about internal interface, then it doesn't
matter, because this can be changed (you don't have to keep BC there
especially for such a new internal interface like this).


> The fact that the I/O rules and coroutine rules are part of a single
> document developed together is actually an advantage, just as the
> existence of separate RFCs for await and Scope is.
>

But are I/O rules really part of this document? There are just a few
mentioning of I/O and that seems more like a leftover from previous version
to me. I don't think it needs to keep reactor in there and mention I/O in
other parts. It should just clearly put it to the future scope to make
clear that this is something that is part of the plan.

Kind regards,

Jakub

--0000000000005b19120643a99449
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Sat, Nov 15, 2025 at 11:03=E2=80=AFPM Edmond Dante=
s &lt;<a href=3D"mailto:edmond.ht@gmail.com">edmond.ht@gmail.com</a>&gt; wr=
ote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">Hello<br>
<br>
&gt; It&#39;s 1.6k lines so it might help a little bit<br>
Yeah :)<br>
<br>
&gt; Why do you need reactor for this specific part of proposal? The thing =
is that there shouldn&#39;t be any IO so you reduce scheduler code as well =
and make it simpler and more reviewable.<br>
<br>
So you are suggesting removing all I/O from the RFC. On the one hand,<br>
that sounds appealing. It immediately eliminates a bunch of tests. But<br>
there is a trap we could all fall into.<br>
By separating the reactor and the scheduler, as well as the rules of<br>
how they work together, we might accidentally introduce an error into<br>
the document simply because the documents would be split.<br>
(interface drift)<br></blockquote><div><br></div><div>I don&#39;t see it th=
at way. You have already implementation showing that this is workable for t=
he proposed user interface so it&#39;s just addition into that. I&#39;m not=
 sure how it could even impact user interface that is being proposed? If yo=
u are talking about internal interface, then it doesn&#39;t matter, because=
 this can be changed (you don&#39;t have to keep BC there especially for su=
ch a new internal interface like this).</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
The fact that the I/O rules and coroutine rules are part of a single<br>
document developed together is actually an advantage, just as the<br>
existence of separate RFCs for await and Scope is. <br></blockquote><div><b=
r></div><div>But are I/O rules really part of this document? There are just=
 a few mentioning of I/O and that seems more like a leftover from previous =
version to me. I don&#39;t think it needs to keep reactor in there and ment=
ion I/O in other parts. It should just clearly put it to the future scope t=
o make clear that this is something that is part of the plan.</div><div><br=
></div><div>Kind regards,</div><div><br></div><div>Jakub</div></div></div>

--0000000000005b19120643a99449--