Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126542
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <c1b1295e-a4c7-434f-8881-2d01a790fd83@rwec.co.uk>
In-Reply-To: <c1b1295e-a4c7-434f-8881-2d01a790fd83@rwec.co.uk>
Date: Sat, 1 Mar 2025 20:34:41 +0200
Message-ID: <CAMW7n8D2+xFUr6a4HDUDz=YWPhJwOXH2ko9TMPFqCFKv1DuwrQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d845a8062f4c2d1e"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000d845a8062f4c2d1e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> 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.
>
>   Thank you for the kind words, it was awesome to read.

  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 anoth=
er.



I can suggest the following workflow:

   1.

   *Approval of the core concept*: Changes affecting the language core.
   2.

   *Decision on the low-level API*: Async\wait + Resume + microtask. Should
   it be exposed to PHP developers or not? (I don=E2=80=99t have a definiti=
ve answer).
   This is a crucial point that impacts 30-40% of the code. If the decision=
 is
   made to hide this API, the code will need to be adjusted.

Next, the RFC can be split into two parts:

   - *Low-level*: Basic PHP primitive functions + C API
   - *High-level*: Future, await, Channel, and maybe Pool.

So the process would be:
3. Approval of the *Low-level RFC*
4. Approval of the *High-level RFC*. Step 4 depends on Step 3 in terms of
implementation but is almost independent in terms of *semantics*. This
means it can be discussed separately and more freely.

Additionally, the *Low-level API* can be released independently, allowing
PHP extensions to adopt concurrency earlier.

As for function names, I really hope for your support in this matter
because it's far from trivial.

Thanks, Ed.

--000000000000d845a8062f4c2d1e
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">First: PHP having native async sup=
port would be a huge step forward for<br>the language. It&#39;s really exci=
ting to see how this proposal develops.<br><br></blockquote><div>=C2=A0 Tha=
nk you for the kind words, it was awesome to read.</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0=C2=A0<span style=3D"fo=
nt-family:Arial,sans-serif;font-size:16px">I wonder if there are ways it ca=
n be split into smaller pieces, so that we don&#39;t overlook details in on=
e part because our focus is drawn to another.</span></blockquote><div>=C2=
=A0</div><div><p>I can suggest the following workflow:</p><ol><li><p><stron=
g>Approval of the core concept</strong>: Changes affecting the language cor=
e.=C2=A0</p></li><li><p><strong>Decision on the low-level API</strong>: <co=
de>Async\wait</code> + <code>Resume=C2=A0+ microtask</code>. Should it be e=
xposed to PHP developers or not? (I don=E2=80=99t have a definitive answer)=
. This is a crucial point that impacts 30-40% of the code. If the decision =
is made to hide this API, the code will need to be adjusted.</p></li></ol><=
p>Next, the RFC can be split into two parts:</p><ul><li><strong>Low-level</=
strong>: Basic PHP primitive functions + C API</li><li><strong>High-level</=
strong>: <code>Future</code>, <code>await</code>, <code>Channel</code>, and=
 maybe=C2=A0<code>Pool</code>.</li></ul><p>So the process would be:<br>3. A=
pproval of the <strong>Low-level RFC</strong><br>4. Approval of the <strong=
>High-level RFC</strong>. Step 4 depends on Step 3 in terms of implementati=
on but is almost independent in terms of <u>semantics</u>. This means it ca=
n be discussed separately and more freely.</p><p>Additionally, the <strong>=
Low-level API</strong> can be released independently, allowing PHP extensio=
ns to adopt concurrency earlier.</p><p>As for function names, I really hope=
 for your support in this matter because it&#39;s far from trivial.</p><p>T=
hanks, Ed.</p></div></div></div>

--000000000000d845a8062f4c2d1e--