Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126687
Precedence: bulk
MIME-Version: 1.0
References: <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com>
 <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@mail.gmail.com>
 <08c8ad0b-e8f4-46e3-99f0-b80748d40b89@app.fastmail.com> <07973EAE-2D83-47A8-8FA0-84286C77C02B@rwec.co.uk>
 <48d66433-3ae9-4895-8361-7c81a0a3670d@app.fastmail.com> <be7cb263-93a1-4bd8-9416-ae4d3e0bafe6@rwec.co.uk>
 <dbce8889-016a-4c59-864c-d8fdec895adc@app.fastmail.com> <CAM0Ccxh=bydoDEHBAV+Gb1_86HJjwhW06kzEsdRiMh93k1F7oA@mail.gmail.com>
 <8599eb8b-d4a3-4cb8-899a-25b134e0d64d@gmail.com> <D73BCCC4-3547-45B4-84AD-A5FD6569D43C@rwec.co.uk>
 <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com> <77DC5F50-531D-49E8-8BE2-504A19CB5FFD@rwec.co.uk>
 <676e36e4-0b84-4d8c-b3db-2998831cd79d@gmail.com> <510B8EF1-9D07-41A8-9EA0-7D99CF7BFC91@rwec.co.uk>
 <bccf099c-55cf-4701-89eb-c26144696eac@gmail.com> <4690cff0-7a48-4fe0-8310-688be253f976@gmail.com>
 <CAMW7n8DTVPkA0qk30TCf1+L3Rmooyt5eEMco+=ds_TX3fEXn-Q@mail.gmail.com>
 <4871b2e4-353e-424f-92b9-7e2bb753bafa@gmail.com> <CAMW7n8Dzin0sYioWFCJHOfaLASLwuSggijV2=2qQA5tO4a0itA@mail.gmail.com>
 <2b7dfacf-fd9f-4692-8b92-b2f22591d32a@app.fastmail.com>
In-Reply-To: <2b7dfacf-fd9f-4692-8b92-b2f22591d32a@app.fastmail.com>
Date: Mon, 10 Mar 2025 11:19:10 +0200
Message-ID: <CAMW7n8DVQ+Oog3nMzDACJg34pojBZXSSLs-0GNiKGf-Ueq+7Ww@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a8e88b062ff9777d"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000a8e88b062ff9777d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>  As noted, I am in broad agreement with the previously linked article on
"playpens" (even if I hate that name), that the "go style model" is too
analogous to goto statements.
>
The syntax and logic you describe are very close to Kotlin's implementation=
.

I would say that Kotlin is probably the best example of structured
concurrency organization, which is closest to PHP in terms of abstraction
level.
One downside I see in Kotlin's syntax is its complexity.

However, what stands out is the *CoroutineScope* concept. Instead of
linking coroutines through *Parent-Child* relationships, Kotlin binds them
to execution contexts. At the same time, the *GlobalScope* context is
accessible everywhere.

https://kotlinlang.org/docs/coroutines-and-channels.html#structured-concurr=
ency

So, it is not the coroutine that maintains the hierarchy, but the *Scope*
object, which essentially aligns with the RFC proposal: contexts can be
hierarchically linked.

This model sounds promising because it relieves coroutines from the
responsibility of waiting for their child coroutines. It is not the
coroutine that should wait, but the *Scope* that should "wait."

```php

spawn function {
    echo "c1\n";
    spawn function {
        echo "c2\n";
    };

    echo "c1 end\n";
};

```

There is no reason to keep *coroutine1* in memory if it does not need
*coroutine2*. However, the *Scope* will remain in memory until all
associated coroutines are completed. This memory model is entirely fair.

Let's consider a scenario with libraries. A library may want to run
coroutines under its own control. This means that the library wants to
execute coroutines within its own *Scope*. For example:

```php

class Logger {
   public function __construct() {
         $this->scope =3D new CoroutineScope();
    }

   public function log(mixed $data) {
         // Adding another coroutine to our personal Scope
         $this->scope->spawn($this->handle_log(...), $data);
   }

   public function __destruct()
   {
      // We can explicitly cancel all coroutines in the destructor if we
find it appropriate
      $this->scope->cancel();
   }
}

```
Default Behavior

By default, the context is always inherited when calling spawn, so there is
no need to pass it explicitly. The expression spawn function {} is
essentially equivalent to currentScope->spawn.

The behavior of an HTTP server in a long-running process would look like
this:

```php

function receiveLoop()
{
    while (true) {
        // Simulating waiting for an incoming connection
        $connection =3D waitForIncomingConnection();

        // Creating a new Scope for handling the request
        $requestScope =3D new CoroutineScope();

        // Processing the request inside its own scope
        $requestScope->spawn(function () use ($connection) {
            handleRequest($connection);
        });
    }
}

```

Scope allows the use of the *"task group"* and *"await all"* patterns
without additional syntax, making it convenient.

```php
$scope =3D new CoroutineScope();

$scope->spawn(function () {
    echo "Task 1 started\n";
    sleep(1);
    echo "Task 1 finished\n";
});

$scope->spawn(function () {
    echo "Task 2 started\n";
    sleep(2);
    echo "Task 2 finished\n";
});

// Wait for all tasks to complete
$scope->awaitAll();

```
What is the advantage of using *Scope* instead of parent-child
relationships in coroutines?

If a programmer *never* uses *Scope*, then the behavior is literally the
same as in *Go*. This means that the programmer does not need structured
relationships, and it does not matter when a particular coroutine completes=
.

At the same time, code at a *higher level* can control the execution of
coroutines created at *lower levels*. The known downside of this approach
is that if lower-level code needs its coroutines to run *independently*, it
must explicitly define this behavior.

According to analysis, this model is effective in most modern languages,
especially those designed for *business logic*.
*Who Will Use Coroutines?*

I believe that the primary consumers of coroutines are *libraries and
frameworks*, which will provide developers with services and logic to solve
tasks.

If a library *refuses* to consider that its coroutine may be *canceled* by
the user's code, or how it should be canceled, it means the library is
*neglecting* its responsibility to provide a proper *contract*.

The *default contract* must give the *user* the *power* to *terminate all
coroutines* launched within a given context because *only the user of the
library knows* when this needs to be done. If a library *has a different
opinion*, then it is *obligated to explicitly implement this behavior*.

This means that *libraries and services bear greater responsibility* than
their users. But isn=E2=80=99t that already the case?

>
> The language simply will not let you write memory-unsafe code
>

And this is more of an *anti-example* than an example.

But this analogy, like any other, cannot be used as an argument *for* or
*against*. *Memory safety* is not the same as launching a coroutine in
GlobalScope.

Where is the danger here? That the coroutine *does something*? But why is
that inherently bad?

It only becomes a problem when a coroutine *accidentally captures memory*
from the current context via use(), leaving an object in memory that *logic=
ally
should have been destroyed* when the request *Scope* was destroyed.

However, you *cannot force* a programmer to avoid writing such code.
Neither *nurseries* nor *structured concurrency* will take away this
possibility.

If a coroutine *does not capture incorrect objects* and *does not wait on
the wrong $channel*, then it should *not* be considered an issue.

>
> I'm not sure if Coroutine would be the right name either
>

I'm not an expert in choosing good names, so I rely on others' opinions. If
the term *coroutine* feels overused, we can look for something else. But
what?

> ($inner->parent ?? $inner)->spawn(escape(...));

But the meaning of this code raises a question: *why am I placing my
coroutine in the parent's context if my own context is already inherited
from the parent?*

Or do I want my coroutine to be destroyed *only* with the parent's context,
but *not* with the current one? But then, *how do I know* that I should
place the coroutine in the *parent*, rather than in the *parent=E2=80=99s p=
arent*?

It makes an assumption about something it *cannot possibly know*.

I would suggest explicitly specifying which *Scope* we want:

```php

function stuff() {
    async $inner {
        // While the request is active
        ($inner->find('requestScope') ?? $inner)->spawn(escape(...));

        // Or while the server is running
        ($inner->find('serverScope') ?? $inner)->spawn(escape(...));
    }
}

```

>
> Edmund, does that make any sense to you?
>

If there are *expert-level* people who have spent years working on language
syntax while also having a *deep understanding of asynchrony*, and they are
willing to help us, I would say that this is not just *reasonable *=E2=80=
=94 it is
more like a *necessary step* that absolutely must be taken.

However, *not for the current RFC*, but rather for a *draft of the next one=
*,
which will focus on a much *narrower* topic. So 100% yes.

In addition to expert input, I would also like to create a database of
real-world use cases from code and examples. This would allow us to use *co=
de
as an argument* against *purely logical reasoning*.

---

Ed

--000000000000a8e88b062ff9777d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;<br>&gt;=C2=A0

As noted, I am in broad agreement with the previously linked article on &qu=
ot;playpens&quot; (even if I hate that name), that the &quot;go style model=
&quot; is too analogous to goto statements.<br>&gt;<div>The syntax and logi=
c you describe are very close to Kotlin&#39;s implementation.</div><div><p>
I would say that Kotlin is probably the best example of structured concurre=
ncy organization, which is closest to PHP in terms of abstraction level.<br=
>
One downside I see in Kotlin&#39;s syntax is its complexity.</p>
<p>However, what stands out is the <strong>CoroutineScope</strong> concept.=
 Instead of linking coroutines through <strong>Parent-Child</strong> relati=
onships, Kotlin binds them to execution contexts. At the same time, the <st=
rong>GlobalScope</strong> context is accessible everywhere.</p><p><a href=
=3D"https://kotlinlang.org/docs/coroutines-and-channels.html#structured-con=
currency">https://kotlinlang.org/docs/coroutines-and-channels.html#structur=
ed-concurrency</a></p><p>So, it is not the coroutine that maintains the hie=
rarchy, but the <strong>Scope</strong> object, which essentially aligns wit=
h the RFC proposal: contexts can be hierarchically linked.</p><p>
</p><p>This model sounds promising because it relieves coroutines from the =
responsibility of waiting for their child coroutines. It is not the corouti=
ne that should wait, but the <strong>Scope</strong> that should &quot;wait.=
&quot;</p><p>```php</p><p>spawn function {<br>=C2=A0 =C2=A0 echo &quot;c1\n=
&quot;;<br>=C2=A0 =C2=A0 spawn function {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ec=
ho &quot;c2\n&quot;;<br>=C2=A0 =C2=A0 };<br><br>=C2=A0 =C2=A0 echo &quot;c1=
 end\n&quot;;<br>};<br></p><p>```</p><p>There is no reason to keep <strong>=
coroutine1</strong> in memory if it does not need <strong>coroutine2</stron=
g>. However, the <strong>Scope</strong> will remain in memory until all ass=
ociated coroutines are completed. This memory model is entirely fair.=C2=A0=
=C2=A0</p><p>Let&#39;s consider a scenario with libraries. A library may wa=
nt to run coroutines under its own control. This means that the library wan=
ts to execute coroutines within its own <strong>Scope</strong>. For example=
:=C2=A0=C2=A0</p><p>```php</p><p>class Logger {<br>=C2=A0 =C2=A0public func=
tion __construct() {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this-&gt;scope =
=3D new CoroutineScope();<br>=C2=A0 =C2=A0 }<br><br>=C2=A0 =C2=A0public fun=
ction log(mixed $data) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Adding ano=
ther coroutine to our personal Scope<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$=
this-&gt;scope-&gt;spawn($this-&gt;handle_log(...), $data);<br>=C2=A0 =C2=
=A0}<br><br>=C2=A0 =C2=A0public function __destruct()<br>=C2=A0 =C2=A0{<br>=
=C2=A0 =C2=A0 =C2=A0 // We can explicitly cancel all coroutines in the dest=
ructor if we find it appropriate

<br>=C2=A0 =C2=A0 =C2=A0 $this-&gt;scope-&gt;cancel();<br>=C2=A0 =C2=A0}<br=
>}<br></p><p>```</p><h3>Default Behavior</h3><p>By default, the context is =
always inherited when calling <code>spawn</code>, so there is no need to pa=
ss it explicitly. The expression <code>spawn function {}</code> is essentia=
lly equivalent to <code>currentScope-&gt;spawn</code>.</p><p>

</p><p>The behavior of an HTTP server in a long-running process would look =
like this:</p><p>```php</p><p>function receiveLoop()<br>{<br>=C2=A0 =C2=A0 =
while (true) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Simulating waiting for an =
incoming connection<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $connection =3D waitForI=
ncomingConnection(); <br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Creating a new =
Scope for handling the request<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $requestScope=
 =3D new CoroutineScope();<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Processing=
 the request inside its own scope<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $requestSc=
ope-&gt;spawn(function () use ($connection) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 handleRequest($connection);<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 });<br>=C2=A0 =C2=A0 }<br>}<br></p><p>```</p><p>Scope allows the use of=
 the <strong>&quot;task group&quot;</strong> and <strong>&quot;await all&qu=
ot;</strong> patterns without additional syntax, making it convenient.=C2=
=A0=C2=A0</p><p>```php<br>$scope =3D new CoroutineScope();<br><br>$scope-&g=
t;spawn(function () {<br>=C2=A0 =C2=A0 echo &quot;Task 1 started\n&quot;;<b=
r>=C2=A0 =C2=A0 sleep(1);<br>=C2=A0 =C2=A0 echo &quot;Task 1 finished\n&quo=
t;;<br>});<br><br>$scope-&gt;spawn(function () {<br>=C2=A0 =C2=A0 echo &quo=
t;Task 2 started\n&quot;;<br>=C2=A0 =C2=A0 sleep(2);<br>=C2=A0 =C2=A0 echo =
&quot;Task 2 finished\n&quot;;<br>});<br><br>// Wait for all tasks to compl=
ete<br>$scope-&gt;awaitAll();<br></p><p>```</p><h3>What is the advantage of=
 using <strong>Scope</strong> instead of parent-child relationships in coro=
utines?</h3><p>If a programmer <strong>never</strong> uses <strong>Scope</s=
trong>, then the behavior is literally the same as in <strong>Go</strong>. =
This means that the programmer does not need structured relationships, and =
it does not matter when a particular coroutine completes.</p><p>At the same=
 time, code at a <strong>higher level</strong> can control the execution of=
 coroutines created at <strong>lower levels</strong>. The known downside of=
 this approach is that if lower-level code needs its coroutines to run <str=
ong>independently</strong>, it must explicitly define this behavior.</p><p>


</p><p>According to analysis, this model is effective in most modern langua=
ges, especially those designed for <strong>business logic</strong>.</p><h3>=
<strong>Who Will Use Coroutines?</strong></h3><p>I believe that the primary=
 consumers of coroutines are <strong>libraries and frameworks</strong>, whi=
ch will provide developers with services and logic to solve tasks.</p><p>If=
 a library <strong>refuses</strong> to consider that its coroutine may be <=
strong>canceled</strong> by the user&#39;s code, or how it should be cancel=
ed, it means the library is <strong>neglecting</strong> its responsibility =
to provide a proper <strong>contract</strong>.</p><p>The <strong>default co=
ntract</strong> must give the <strong>user</strong> the <strong>power</stro=
ng> to <strong>terminate all coroutines</strong> launched within a given co=
ntext because <strong>only the user of the library knows</strong> when this=
 needs to be done. If a library <strong>has a different opinion</strong>, t=
hen it is <strong>obligated to explicitly implement this behavior</strong>.=
</p><p>



</p><p>This means that <strong>libraries and services bear greater responsi=
bility</strong> than their users. But isn=E2=80=99t that already the case?<=
/p><p>&gt;<br>&gt;=C2=A0<span style=3D"background-color:rgb(242,242,242);co=
lor:rgb(51,51,51);font-family:&quot;Fira Mono&quot;,monospace;font-size:14p=
x">The language simply will not let you write=C2=A0</span><font color=3D"#3=
33333" face=3D"Fira Mono, monospace"><span style=3D"font-size:14px;backgrou=
nd-color:rgb(242,242,242)">memory-unsafe code<br></span></font>&gt;<br><br>=
And this is more of an <strong>anti-example</strong> than an example.=C2=A0=
=C2=A0</p><p>But this analogy, like any other, cannot be used as an argumen=
t <strong>for</strong> or <strong>against</strong>. <strong>Memory safety</=
strong> is not the same as launching a coroutine in <code>GlobalScope</code=
>.</p><p>Where is the danger here? That the coroutine <strong>does somethin=
g</strong>? But why is that inherently bad?</p><p>It only becomes a problem=
 when a coroutine <strong>accidentally captures memory</strong> from the cu=
rrent context via <code>use()</code>, leaving an object in memory that <str=
ong>logically should have been destroyed</strong> when the request <strong>=
Scope</strong> was destroyed.</p><p>However, you <strong>cannot force</stro=
ng> a programmer to avoid writing such code. Neither <strong>nurseries</str=
ong> nor <strong>structured concurrency</strong> will take away this possib=
ility.</p><p>



</p><p>If a coroutine <strong>does not capture incorrect objects</strong> a=
nd <strong>does not wait on the wrong <code>$channel</code></strong>, then =
it should <strong>not</strong> be considered an issue.</p><p>&gt;<br>&gt;=
=C2=A0<font color=3D"#333333" face=3D"Fira Mono, monospace"><span style=3D"=
font-size:14px;background-color:rgb(242,242,242)">I&#39;m not sure if Corou=
tine would be the right name either<br></span></font>&gt;<br><br>I&#39;m no=
t an expert in choosing good names, so I rely on others&#39; opinions. If t=
he term <strong>coroutine</strong> feels overused, we can look for somethin=
g else. But what?</p><pre style=3D"box-sizing:border-box;font-family:&quot;=
Fira Mono&quot;,monospace;font-size:14px;color:rgb(51,51,51);background-col=
or:rgb(242,242,242)">&gt; ($inner-&gt;parent ?? $inner)-&gt;spawn(escape(..=
.));
</pre><p>But the meaning of this code raises a question: <strong>why am I p=
lacing my coroutine in the parent&#39;s context if my own context is alread=
y inherited from the parent?</strong></p><p>Or do I want my coroutine to be=
 destroyed <strong>only</strong> with the parent&#39;s context, but <strong=
>not</strong> with the current one? But then, <strong>how do I know</strong=
> that I should place the coroutine in the <strong>parent</strong>, rather =
than in the <strong>parent=E2=80=99s parent</strong>?</p><p>

</p><p>It makes an assumption about something it <strong>cannot possibly kn=
ow</strong>.</p><p>I would suggest explicitly specifying which <strong>Scop=
e</strong> we want:=C2=A0=C2=A0</p><p>```php</p><p>function stuff() {<br>=
=C2=A0 =C2=A0 async $inner {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // While the re=
quest is active<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ($inner-&gt;find(&#39;reques=
tScope&#39;) ?? $inner)-&gt;spawn(escape(...));<br><br>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 // Or while the server is running<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ($=
inner-&gt;find(&#39;serverScope&#39;) ?? $inner)-&gt;spawn(escape(...));<br=
>=C2=A0 =C2=A0 }<br>}<br></p><p>```</p><p>&gt;<br>&gt; Edmund, does that ma=
ke any sense to you?<br>&gt;=C2=A0=C2=A0</p><p>If there are <strong>expert-=
level</strong> people who have spent years working on language syntax while=
 also having a <strong>deep understanding of asynchrony</strong>, and they =
are willing to help us, I would say that this is not just <strong>reasonabl=
e=C2=A0</strong>=E2=80=94 it is more like a <strong>necessary step</strong>=
 that absolutely must be taken.</p><p>However, <strong>not for the current =
RFC</strong>, but rather for a <strong>draft of the next one</strong>, whic=
h will focus on a much <strong>narrower</strong> topic. So 100% yes.</p><p>

</p><p>In addition to expert input, I would also like to create<strong>=C2=
=A0</strong>a database of real-world use cases from code and examples. This=
 would allow us to use <strong>code as an argument</strong> against <strong=
>purely logical reasoning</strong>.=C2=A0</p><p>---</p><p>Ed</p></div></div=
>

--000000000000a8e88b062ff9777d--