Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126917
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
In-Reply-To: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
Date: Sun, 23 Mar 2025 19:48:38 +0200
Message-ID: <CAMW7n8DTsvODNiy3ajv9u6Q8mJM2JztyQCiZzx88p-grxFdhMw@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP True Async RFC - Stage 2
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009f2d0506310619d4"
From: edmond.ht@gmail.com (Edmond Dantes)

--0000000000009f2d0506310619d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

It's a nice Sunday evening, and I'd like to share some updates and thoughts
from this week =E2=80=94 kind of like a digest :)

1. Big thanks to Rowan Tommins for the syntax suggestions, ideas, and
feedback. I decided to try using the `spawn block` syntax, and in practice,
it turned out to be quite convenient. So I'll include it in the next phase.
You can check out the details via the link:
https://github.com/EdmondDantes/php-true-async-rfc/blob/main/basic.md#spawn=
-closure-syntax

```php
function startServer(): void
{
    async $serverSupervisor {

      // Secondary coroutine that listens for a shutdown signal
      spawn use($serverSupervisor) {
         await Async\signal(SIGINT);
         $serverSupervisor->cancel(new CancellationException("Server
shutdown"));
      }

      // Main coroutine that listens for incoming connections
      await spawn {
            while ($socket =3D stream_socket_accept($serverSocket, 0)) {

                connectionHandler($socket);
            }
        };
    }
}
```

2. suspend has become a statement.

3. The scope retrieval functions like currentScope, globalScope, and
rootScope have been removed. This has consequences. One of them: it's no
longer possible to create a "detached" coroutine. But that=E2=80=99s good n=
ews.

4. I decided to borrow Larry's example and create a special code block "*as=
ync
block"* that interacts with coroutine Scope in a special way.

```php
function startServer(): void
{
    async $serverSupervisor {

      // Secondary coroutine that listens for a shutdown signal
      spawn use($serverSupervisor) {
         await Async\signal(SIGINT);
         $serverSupervisor->cancel(new CancellationException("Server
shutdown"));
      }

      // Main coroutine that listens for incoming connections
      await spawn {
            while ($socket =3D stream_socket_accept($serverSocket, 0)) {

                connectionHandler($socket);
            }
        };
    }
}
```

It looks nice, even though it's syntactic sugar for:

```php
$scope =3D new Scope();

try {
   await spawn in $scope {
       echo "Task 1\n";
   };
} finally {
    $scope->dispose();
}
```

This syntax creates a code block that limits the lifetime of coroutines
until the block is exited. It doesn't *wait*, it *limits*. Besides the fact
that the block looks compact, it can be checked by static analysis for the
presence of `await`, verify what exactly is being awaited, and report
potential errors. In other words, such code is much easier to analyze and
to establish relationships between groups of coroutines.

The downside is that it's not suitable for classes with destructors. But
that's not really a drawback, since there's a different approach for
handling classes.

5. I decided to abandon `await all + scope`.

Reason: it's too tempting to shoot yourself in the foot.

Instead of `await $scope`, I want the programmer to explicitly choose what
exactly they intend to wait for: only direct children or all others. If
you're going to shoot yourself in the foot =E2=80=94 do it with full awaren=
ess :)

Drawback: it complicates the logic. But on the other hand, this approach
makes the code better.

The code only awaits the coroutines that were created inside the foreach:

```php
function processAllUsers(string ...$users): array
{
    $scope =3D new Scope();

    foreach ($users as $user) {
        spawn in $scope processUser($user);
    }

    return await $scope->tasks();
}
```

Code that waits until all child coroutines =E2=80=94 at any depth =E2=80=94=
 of the launched
background tasks have completed.

```php
function processBackgroundJobs(string ...$jobs): array
{
    $scope =3D new Scope();

    foreach ($jobs as $job) {
        spawn with $scope processJob($users);
    }

    await $scope->all();
}
```

It doesn=E2=80=99t look terrible, but I=E2=80=99m concerned that this kind =
of functionality
might feel =E2=80=9Ccomplex=E2=80=9D from a learning curve perspective. On =
the other hand,
Python=E2=80=99s approach to similar things is even more complex, largely b=
ecause
the language added async features in several stages.

My main doubts revolve around the fact that Scope is passed implicitly
between function calls. This creates multiple usage scenarios =E2=80=94 i.e=
., a
kind of flexibility that no other language really has. And as we know,
flexibility has a dark side: it opens up ways to break everything.

On one hand, this RFC effectively allows writing in the style of Go,
Kotlin, C#, or even some other paradigms. On the other hand, identifying
the =E2=80=9Cdark side of the force=E2=80=9D becomes harder.

If you don=E2=80=99t use Scope =E2=80=94 you=E2=80=99re writing Go-style co=
de.
If you use Scope + all + async =E2=80=94 it=E2=80=99s Kotlin.
If you use Scope + tasks() =E2=80=94 it=E2=80=99s more like Elixir.

And you can also just pass $scope explicitly from function to function =E2=
=80=94
then you get super-explicit structured concurrency.

So I keep asking myself: wouldn=E2=80=99t it have been simpler to just impl=
ement
the Go model? :)
How can you know in advance that the chosen solution won=E2=80=99t lead to =
twisted
practices or eventually result in anti-patterns?
How can you tell if the chosen toolkit is strict enough =E2=80=94 and not *=
too*
flexible?

These questions are the main reason why the next revision won=E2=80=99t be =
released
very soon. More code and examples are needed to understand how reliable
this really is.

But in the meantime, you can keep an eye on this:
https://github.com/EdmondDantes/php-true-async-rfc/blob/main/basic.md

--0000000000009f2d0506310619d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div><div>Hello everyone,<br><br>It&#39;s a nice=
 Sunday evening, and I&#39;d like to share some updates and thoughts from t=
his week =E2=80=94 kind of like a digest :)<br><br>1. Big thanks to Rowan T=
ommins for the syntax suggestions, ideas, and feedback. I decided to try us=
ing the `spawn block` syntax, and in practice, it turned out to be quite co=
nvenient. So I&#39;ll include it in the next phase. You can check out the d=
etails via the link: <a href=3D"https://github.com/EdmondDantes/php-true-as=
ync-rfc/blob/main/basic.md#spawn-closure-syntax">https://github.com/EdmondD=
antes/php-true-async-rfc/blob/main/basic.md#spawn-closure-syntax</a></div><=
div><br></div><div>```php</div><div>function startServer(): void<br>{<br>=
=C2=A0 =C2=A0 async $serverSupervisor {<br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 =
=C2=A0 // Secondary coroutine that listens for a shutdown signal<br>=C2=A0 =
=C2=A0 =C2=A0 spawn use($serverSupervisor) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0await Async\signal(SIGINT);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$se=
rverSupervisor-&gt;cancel(new CancellationException(&quot;Server shutdown&q=
uot;));<br>=C2=A0 =C2=A0 =C2=A0 } =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 <br>=C2=A0=
 =C2=A0 =C2=A0 // Main coroutine that listens for incoming connections<br>=
=C2=A0 =C2=A0 =C2=A0 await spawn {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 while ($socket =3D stream_socket_accept($serverSocket, 0)) { =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 connectionHandler($socket);<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };<br>=C2=A0 =C2=A0 }=
<br>}</div><div>```</div><div><br></div><div>2.=C2=A0<code>suspend</code> h=
as become a statement.</div><div><br></div><div>3. The scope retrieval func=
tions like <code>currentScope</code>, <code>globalScope</code>, and <code>r=
ootScope</code> have been removed. This has consequences. One of them: it&#=
39;s no longer possible to create a &quot;detached&quot; coroutine. But tha=
t=E2=80=99s good news.</div><div><br></div><div>4. I decided to borrow Larr=
y&#39;s example and create a special code block &quot;<b>async block&quot;<=
/b> that interacts with coroutine <code>Scope</code> in a special way.=C2=
=A0</div><div><br></div><div>```php<br>function startServer(): void<br>{<br=
>=C2=A0 =C2=A0 async $serverSupervisor {<br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0=
 =C2=A0 // Secondary coroutine that listens for a shutdown signal<br>=C2=A0=
 =C2=A0 =C2=A0 spawn use($serverSupervisor) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0await Async\signal(SIGINT);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
$serverSupervisor-&gt;cancel(new CancellationException(&quot;Server shutdow=
n&quot;));<br>=C2=A0 =C2=A0 =C2=A0 } =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 <br>=C2=
=A0 =C2=A0 =C2=A0 // Main coroutine that listens for incoming connections<b=
r>=C2=A0 =C2=A0 =C2=A0 await spawn {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 while ($socket =3D stream_socket_accept($serverSocket, 0)) { =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 connectionHandler($socket);<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 };<br>=C2=A0 =C2=A0 }=
<br>}<br>```<br></div><div><br></div><div>It looks nice, even though it&#39=
;s syntactic sugar for:<br><br></div><div>```php<br>$scope =3D new Scope();=
<br><br>try {<br>=C2=A0 =C2=A0await spawn in $scope {<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0echo &quot;Task 1\n&quot;;<br>=C2=A0 =C2=A0};<br>} finally {<br>=
=C2=A0 =C2=A0 $scope-&gt;dispose();<br>}<br>```<br></div><div><br></div><di=
v>This syntax creates a code block that limits the lifetime of coroutines u=
ntil the block is exited. It doesn&#39;t *wait*, it *limits*. Besides the f=
act that the block looks compact, it can be checked by static analysis for =
the presence of `await`, verify what exactly is being awaited, and report p=
otential errors. In other words, such code is much easier to analyze and to=
 establish relationships between groups of coroutines.<br><br>The downside =
is that it&#39;s not suitable for classes with destructors. But that&#39;s =
not really a drawback, since there&#39;s a different approach for handling =
classes.<br></div><div><br></div><div>5. I decided to abandon `await all + =
scope`.</div><br>Reason: it&#39;s too tempting to shoot yourself in the foo=
t.<br><br>Instead of `await $scope`, I want the programmer to explicitly ch=
oose what exactly they intend to wait for: only direct children or all othe=
rs. If you&#39;re going to shoot yourself in the foot =E2=80=94 do it with =
full awareness :)<br><br>Drawback: it complicates the logic. But on the oth=
er hand, this approach makes the code better.<br><div><br></div><div>The co=
de only awaits the coroutines that were created inside the <code>foreach:</=
code>=C2=A0=C2=A0</div><div><br></div><div>```php<br>function processAllUse=
rs(string ...$users): array<br>{<br>=C2=A0 =C2=A0 $scope =3D new Scope();<b=
r>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 foreach ($users as $user) {<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 spawn in $scope processUser($user);<br>=C2=A0 =C2=A0 }<br=
>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 return await $scope-&gt;tasks();<br>}<br>`=
``<br></div><div><br></div><div>Code that waits until all child coroutines =
=E2=80=94 at any depth =E2=80=94 of the launched background tasks have comp=
leted.</div><div><br></div><div>```php</div><div>function processBackground=
Jobs(string ...$jobs): array<br>{<br>=C2=A0 =C2=A0 $scope =3D new Scope();<=
br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 foreach ($jobs as $job) {<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 spawn with $scope processJob($users);<br>=C2=A0 =C2=A0 }<=
br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 await $scope-&gt;all();<br>}<br>```<br><=
/div><div><br></div><div><p class=3D"gmail-">It doesn=E2=80=99t look terrib=
le, but I=E2=80=99m concerned that this kind of functionality might feel =
=E2=80=9Ccomplex=E2=80=9D from a learning curve perspective. On the other h=
and, Python=E2=80=99s approach to similar things is even more complex, larg=
ely because the language added async features in several stages.</p>
<p class=3D"gmail-">My main doubts revolve around the fact that <code>Scope=
</code> is passed implicitly between function calls. This creates multiple =
usage scenarios =E2=80=94 i.e., a kind of flexibility that no other languag=
e really has. And as we know, flexibility has a dark side: it opens up ways=
 to break everything.</p>
<p class=3D"gmail-">On one hand, this RFC effectively allows writing in the=
 style of Go, Kotlin, C#, or even some other paradigms. On the other hand, =
identifying the =E2=80=9Cdark side of the force=E2=80=9D becomes harder.</p=
>
<p class=3D"gmail-">If you don=E2=80=99t use <code>Scope</code> =E2=80=94 y=
ou=E2=80=99re writing Go-style code.<br>
If you use <code>Scope</code> + <code>all</code> + <code>async</code> =E2=
=80=94 it=E2=80=99s Kotlin.<br>
If you use <code>Scope</code> + <code>tasks()</code> =E2=80=94 it=E2=80=99s=
 more like Elixir.</p>
<p class=3D"gmail-">And you can also just pass <code>$scope</code> explicit=
ly from function to function =E2=80=94 then you get super-explicit structur=
ed concurrency.</p>
<p class=3D"gmail-">So I keep asking myself: wouldn=E2=80=99t it have been =
simpler to just implement the Go model? :)</p></div><div>How can you know i=
n advance that the chosen solution won=E2=80=99t lead to twisted practices =
or eventually result in anti-patterns?<br>
How can you tell if the chosen toolkit is strict enough =E2=80=94 and not <=
em>too</em> flexible?=C2=A0=C2=A0</div><div><br></div><div><p class=3D"gmai=
l-">These questions are the main reason why the next revision won=E2=80=99t=
 be released very soon. More code and examples are needed to understand how=
 reliable this really is.</p>
<p class=3D"gmail-">But in the meantime, you can keep an eye on this:</p></=
div><div><a href=3D"https://github.com/EdmondDantes/php-true-async-rfc/blob=
/main/basic.md">https://github.com/EdmondDantes/php-true-async-rfc/blob/mai=
n/basic.md</a></div></div>

--0000000000009f2d0506310619d4--