Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127130
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8BVd-dqcy7tabMEcOOLZPcqWj9o64tEVPepvHxcQ2BPzQ@mail.gmail.com>
 <EE188994-2384-4226-8C09-B786279C5998@rwec.co.uk>
In-Reply-To: <EE188994-2384-4226-8C09-B786279C5998@rwec.co.uk>
Date: Thu, 17 Apr 2025 11:54:26 +0300
Message-ID: <CAMW7n8C+jtqeprvz_h8mXBw1mNp1ZrWrqNPoVpv6=H3Qc5H3iw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 3
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000313cf00632f58d52"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000313cf00632f58d52
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello, Rowan!

> I don't have time to dig into the details of this draft at the moment,
but will say that a vote in two weeks is not at all realistic.
I just used the Flow from the Wiki. :)

> My only other comment at a very quick glance is that I see the Context
section is still included, and still has most of its complexity.
Almost every section of the RFC has a "Motivation" subsection, which
explains why a particular tool is needed and what problem it solves.
I removed everything from the RFC that is not directly related to
asynchrony or not essential at this stage.

Yesterday I also received feedback that the RFC contains too many changes,
so I can briefly summarize what=E2=80=99s new in this version compared to t=
he
previous one:

   1.

   The Scope class can no longer be used in an await expression. A separate
   method is now provided for waiting on a Scope, intended only for special
   use cases.
   2.

   Scope is now responsible solely for coroutine lifetime and error
   handling.
   3.

   A TaskGroup class has been added for working with groups of tasks. It is
   used explicitly with the expression spawn with $taskGroup. Together with
   Scope, TaskGroup supports structured concurrency, offering different
   strategies for tracking hanging coroutines.

*These are the key changes.*

*Secondary changes include:*

   1.

   Syntax refinement
   2.

   Edge case handling
   3.

   Ability to extend spawn with logic
   4.

   Added combinator functions: all, any, anyOf, ignoreErrors
   5.

   A special function Async\protect() has been added for critical sections
   that cannot be cancelled.
   6.

   Improved examples

Contextual expressions like with $context and async blocks were removed
from the RFC as they are out of its scope.

The next important step is to determine which coroutine model to choose.
There are three models in total:

   1.

   Go =E2=80=93 no Scope
   2.

   Java Loom =E2=80=93 Scope is always passed explicitly
   3.

   The current RFC =E2=80=93 Scope is passed both explicitly and implicitly

The choice of model affects both the syntax and the API. Therefore, if the
current model is not accepted, there is no point in further developing this
RFC =E2=80=94 a new one should be created instead.

This is the key question I want to clarify at this stage.

--

Ed

--000000000000313cf00632f58d52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello, Rowan!</div><div dir=3D"ltr"><br></div><div di=
r=3D"ltr">&gt; I don&#39;t have time to dig into the details of this draft =
at the moment, but will say that a vote in two weeks is not at all realisti=
c.<br>I just used the Flow from the Wiki. :)</div><div dir=3D"ltr"><br></di=
v><div dir=3D"ltr">&gt; My only other comment at a very quick glance is tha=
t I see the Context section is still included, and still has most of its co=
mplexity.</div><div dir=3D"ltr">Almost every section of the RFC has a &quot=
;Motivation&quot; subsection, which explains why a particular tool is neede=
d and what problem it solves.=C2=A0</div><div dir=3D"ltr">I removed everyth=
ing from the RFC that is not directly related to asynchrony or not essentia=
l at this stage.=C2=A0=C2=A0</div><div class=3D"gmail_quote gmail_quote_con=
tainer"><div><br></div><p class=3D"gmail-">Yesterday I also received feedba=
ck that the RFC contains too many changes, so I can briefly summarize what=
=E2=80=99s new in this version compared to the previous one:</p>
<ol>
<li class=3D"gmail-">
<p class=3D"gmail-">The <code>Scope</code> class can no longer be used in a=
n <code>await</code> expression. A separate method is now provided for wait=
ing on a Scope, intended only for special use cases.</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-"><code>Scope</code> is now responsible solely for corout=
ine lifetime and error handling.</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">A <code>TaskGroup</code> class has been added for worki=
ng with groups of tasks. It is used explicitly with the expression <code>sp=
awn with $taskGroup</code>. Together with <code>Scope</code>, <code>TaskGro=
up</code> supports structured concurrency, offering different strategies fo=
r tracking hanging coroutines.</p>
</li>
</ol>
<p class=3D"gmail-"><strong>These are the key changes.</strong><strong><br>=
</strong></p><p class=3D"gmail-"><strong>Secondary changes include:</strong=
></p>
<ol>
<li class=3D"gmail-">
<p class=3D"gmail-">Syntax refinement</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">Edge case handling</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">Ability to extend <code>spawn with</code> logic</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">Added combinator functions: <code>all</code>, <code>any=
, anyOf, ignoreErrors</code></p>
</li><li class=3D"gmail-"><p class=3D"gmail-">A special function Async\prot=
ect() has been added for critical sections that cannot be cancelled.=C2=A0=
=C2=A0</p></li>
<li class=3D"gmail-">
<p class=3D"gmail-">Improved examples</p>
</li>
</ol>
<div>Contextual expressions like <code>with $context</code> and <code>async=
</code> blocks were removed from the RFC as they are out of its scope.=C2=
=A0</div><div><br></div><div>The next important step is to determine which =
coroutine model to choose. There are three models in total:</div><div>
<ol>
<li class=3D"gmail-">
<p class=3D"gmail-">Go =E2=80=93 no Scope</p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">Java Loom =E2=80=93 Scope is always passed explicitly</=
p>
</li>
<li class=3D"gmail-">
<p class=3D"gmail-">The current RFC =E2=80=93 Scope is passed both explicit=
ly and implicitly</p>
</li>
</ol>
<p class=3D"gmail-">The choice of model affects both the syntax and the API=
. Therefore, if the current model is not accepted, there is no point in fur=
ther developing this RFC =E2=80=94 a new one should be created instead.</p>=
<p class=3D"gmail-">This is the key question I want to clarify at this stag=
e.=C2=A0=C2=A0</p><p class=3D"gmail-">--</p><p class=3D"gmail-">Ed</p></div=
></div></div>

--000000000000313cf00632f58d52--