Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128981
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CAMW7n8BxmAC56LZ4qA6oJp0kFhhPMuLdqfmzeSVQrf6woR9GyA@mail.gmail.com> <889d3042-7b3e-4152-bd8c-09bbcc967309@app.fastmail.com>
In-Reply-To: <889d3042-7b3e-4152-bd8c-09bbcc967309@app.fastmail.com>
Date: Mon, 27 Oct 2025 18:18:04 +0200
Message-ID: <CAAwdEzA6Wr2OxwqoFb3kJXvceRFUdYi4o7uHc7mTV5Men7=dOg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 4
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a2ebbd0642263f99"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000a2ebbd0642263f99
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>
>
> On Mon, Oct 27, 2025 at 6:05=E2=80=AFPM Larry Garfield <larry@garfieldtec=
h.com>
> wrote:
>
>> On Mon, Oct 27, 2025, at 7:08 AM, Edmond Dantes wrote:
>> > Hello all.
>> >
>> > ### Current work and discussion plan for this RFC
>> >
>> > 1. By the end of this week, the proposed changes at
>> >
>> > [
>> https://github.com/true-async/php-true-async-rfc/issues](https://github.=
com/true-async/php-true-async-rfc/issues)
>> >    will be accepted if no objections are raised.
>> >
>> > 2. After that, the RFC document will be updated, and a new **2-week
>> > discussion period** will begin.
>> >
>> > 3. After the new changes are accepted, the RFC will be updated again,
>> > and the process will repeat.
>> >
>> > The discussion will be extended as long as necessary, including at the
>> > request of the participants.
>> >
>> > ---
>> > With best regards,
>> > Ed
>>
>> I am not sure how feasible this is, but would there be a way to split th=
e
>> "async toggle" of IO operations off to its own PR/RFC?  To me, that is b=
y
>> far the most important part of this RFC as that's the biggest blocker fo=
r
>> wider async adoption, but I'm not sure how many layers are needed above =
it
>> to make it possible to toggle in a safe fashion.
>>
>
> Hi!
>
> Can you clarify what you mean by "async toggle"?
> Is it the actual implementation that would use async constructs if the
> current context is a coroutine for each implementation of IO functions?
> Yes, for that, it would be nice to have separate PRs, even multiple ones
> for easier review. But maybe you mean something else...
>
> --
> Alex
>

--000000000000a2ebbd0642263f99
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><br><div dir=3D"ltr" class=3D"gmai=
l_attr"><br class=3D"gmail-Apple-interchange-newline">On Mon, Oct 27, 2025 =
at 6:05=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.=
com">larry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">On Mon, Oct 27, 2025, at 7:08 AM, Edmond Dantes =
wrote:<br>&gt; Hello all.<br>&gt;<br>&gt; ### Current work and discussion p=
lan for this RFC<br>&gt;<br>&gt; 1. By the end of this week, the proposed c=
hanges at<br>&gt;=C2=A0 =C2=A0<br>&gt; [<a href=3D"https://github.com/true-=
async/php-true-async-rfc/issues%5D(https://github.com/true-async/php-true-a=
sync-rfc/issues)" rel=3D"noreferrer" target=3D"_blank">https://github.com/t=
rue-async/php-true-async-rfc/issues](https://github.com/true-async/php-true=
-async-rfc/issues)</a><br>&gt;=C2=A0 =C2=A0 will be accepted if no objectio=
ns are raised.<br>&gt;<br>&gt; 2. After that, the RFC document will be upda=
ted, and a new **2-week<br>&gt; discussion period** will begin.<br>&gt;<br>=
&gt; 3. After the new changes are accepted, the RFC will be updated again,<=
br>&gt; and the process will repeat.<br>&gt;<br>&gt; The discussion will be=
 extended as long as necessary, including at the<br>&gt; request of the par=
ticipants.<br>&gt;<br>&gt; ---<br>&gt; With best regards,<br>&gt; Ed<br><br=
>I am not sure how feasible this is, but would there be a way to split the =
&quot;async toggle&quot; of IO operations off to its own PR/RFC?=C2=A0 To m=
e, that is by far the most important part of this RFC as that&#39;s the big=
gest blocker for wider async adoption, but I&#39;m not sure how many layers=
 are needed above it to make it possible to toggle in a safe fashion.<br></=
blockquote><div><br></div><div>Hi!</div><div><br></div><div>Can you clarify=
 what you mean by &quot;async toggle&quot;?</div><div>Is it the actual impl=
ementation that would use async constructs if the current context=C2=A0is a=
 coroutine for each implementation=C2=A0of IO functions?</div><div>Yes, for=
 that, it would be nice to have separate PRs, even multiple ones for easier=
 review. But maybe you mean something else...</div><div>=C2=A0</div><div>--=
=C2=A0</div><div>Alex</div>
</blockquote></div></div>

--000000000000a2ebbd0642263f99--