Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126596
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
 <9964db8c-0ffe-43d5-8246-47fc76b07180@app.fastmail.com> <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com>
 <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com> <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com>
In-Reply-To: <bb7a9f8f-0422-45e5-b4fc-f5757add92b4@app.fastmail.com>
Date: Thu, 6 Mar 2025 10:52:17 +0200
Message-ID: <CAMW7n8BnzL7d0bd_Y_jGOmyWegKQpm-FzrVFRCcDe=bNFZpi+A@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="0000000000003efff5062fa8a02c"
From: edmond.ht@gmail.com (Edmond Dantes)

--0000000000003efff5062fa8a02c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  One key question, if we disallow explicitly creating Fibers inside an
async block,
> can a Fiber be created outside of it and not block async, or would that
also be excluded?  Viz, this is illegal:
>

Creating a `Fiber` outside of an asynchronous block is allowed; this
ensures backward compatibility.
According to the logic integrity rule, an asynchronous block cannot be
created inside a Fiber. This is a correct statement.

However, if the asynchronous block blocks execution, then it does not
matter whether a Fiber was created or not, because it will not be possible
to switch it in any way.
So, the answer to your question is: yes, such code is legal, but the Fiber
will not be usable for switching.

In other words, Fiber and an asynchronous block are mutually exclusive.
Only one of them can be used at a time: either Fiber + Revolt or an
asynchronous block.

Of course, this is not an elegant solution, as it adds one more rule to the
language, making it more complex. However, from a legacy perspective, it
seems like a minimal scar.

(to All: Please leave your opinion if you are reading this )

>  // This return statement blocks until foo() and bar() complete.

Yes, *that's correct*. That's exactly what I mean.

Of course, under the hood, return will execute immediately if the coroutine
is not waiting for anything. However, the Scheduler will store its result
and pause it until the child coroutines finish their work.

In essence, this follows the parent-child coroutine pattern, where they are
always linked. The downside is that it requires more code inside the
implementation, and some people might accuse us of a paternalistic
approach. :)

>
> should consider if async {} makes sense to have its own catch and finally
blocks built in.)
>
We can use the approach from the RFC to catch exceptions from child
coroutines: explicit waiting, which creates a handover point for exceptions=
.

Alternatively, a separate handler like Context::catch() could be
introduced, which can be defined at the beginning of the coroutine.

Or both approaches could be supported. There's definitely something to
think about here.

>
>  That is still dependency injection, because ThingRunner is still taking
all of its dependencies via the constructor.  And being readonly, it's
still immutable-friendly.
>

Yeah, so basically, you're creating the service again and again for each
coroutine if the coroutine needs to use it. This is a good solution in the
context of multitasking, but it loses in terms of performance and memory,
as well as complexity and code size, because it requires more factory
classes.

The main advantage of *LongRunning* is initializing once and using it
multiple times. On the other hand, this approach explicitly manages memory,
ensuring that all objects are created within the coroutine's context rather
than in the global context.

Ah, now I see how much you dislike global state! :)

However, in a scenario where a web server handles many similar requests,
"global state" might not necessarily win in terms of speed but rather due
to the simplicity of implementation and the overall maintenance cost of the
code. (I know that in programming, there is an entire camp of immutability
advocates who preach that their approach is the key remedy for errors.)

I would support both paradigms, especially since it doesn=E2=80=99t cost mu=
ch.

A coroutine will own its internal context anyway, and this context will be
carried along with it, even across threads. How to use this context is up
to the programmer to decide.  But at the same time, I will try to make the
pattern you described fit seamlessly into this logic.

Ed.

--0000000000003efff5062fa8a02c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0

One key question, if we disallow explicitly creating Fibers inside an async=
 block, <br>&gt; can a Fiber be created outside of it and not block async, =
or would that also be excluded?=C2=A0 Viz, this is illegal:<br>&gt;<br><p>C=
reating a `Fiber` outside of an asynchronous block is allowed; this ensures=
 backward compatibility.<br>According to the logic integrity rule, an async=
hronous block cannot be created inside a Fiber. This is a correct statement=
.</p><p>However, if the asynchronous block blocks execution, then it does n=
ot matter whether a Fiber was created or not, because it will not be possib=
le to switch it in any way.<br>So, the answer to your question is: yes, suc=
h code is legal, but the Fiber will not be usable for switching.</p><p>In o=
ther words, Fiber and an asynchronous block are mutually exclusive. Only on=
e of them can be used at a time: either Fiber + Revolt or an asynchronous b=
lock.</p><p>Of course, this is not an elegant solution, as it adds one more=
 rule to the language, making it more complex. However, from a legacy persp=
ective, it seems like a minimal scar.</p><p>(to All: Please leave your opin=
ion if you are reading this )<br><br>&gt;=C2=A0 // This return statement bl=
ocks until foo() and bar() complete.<br></p><p>Yes, <b>that&#39;s correct</=
b>. That&#39;s exactly what I mean.</p><p>Of course, under the hood, <code>=
return</code> will execute immediately if the coroutine is not waiting for =
anything. However, the Scheduler will store its result and pause it until t=
he child coroutines finish their work.</p><p>In essence, this follows the p=
arent-child coroutine pattern, where they are always linked. The downside i=
s that it requires more code inside the implementation, and some people mig=
ht accuse us of a paternalistic approach. :)</p><p>&gt;=C2=A0<br>&gt;=C2=A0=
<span style=3D"background-color:rgb(242,242,242);color:rgb(51,51,51);font-f=
amily:&quot;Fira Mono&quot;,monospace;font-size:14px">should consider if as=
ync {} makes sense to have its own catch and finally blocks=C2=A0</span><fo=
nt color=3D"#333333" face=3D"Fira Mono, monospace"><span style=3D"font-size=
:14px;background-color:rgb(242,242,242)">built in.)<br></span></font>&gt;=
=C2=A0<br>We can use the approach from the RFC to catch exceptions from chi=
ld coroutines: explicit waiting, which creates a handover point for excepti=
ons.</p><p>Alternatively, a separate handler like <code>Context::catch()</c=
ode> could be introduced, which can be defined at the beginning of the coro=
utine.</p><p>Or both approaches could be supported. There&#39;s definitely =
something to think about here.</p><p>&gt;=C2=A0<br>&gt;=C2=A0

That is still dependency injection, because ThingRunner is still taking all=
 of its dependencies via the constructor.=C2=A0 And being readonly, it&#39;=
s still immutable-friendly.<br>&gt;=C2=A0</p><p>Yeah, so basically, you&#39=
;re creating the service again and again for each coroutine if the coroutin=
e needs to use it. This is a good solution in the context of multitasking, =
but it loses in terms of performance and memory, as well as complexity and =
code size, because it requires more factory classes.</p><p>The main advanta=
ge of <em>LongRunning</em> is initializing once and using it multiple times=
. On the other hand, this approach explicitly manages memory, ensuring that=
 all objects are created within the coroutine&#39;s context rather than in =
the global context.</p><p>Ah, now I see how much you dislike global state! =
:)</p><p>However, in a scenario where a web server handles many similar req=
uests, &quot;global state&quot; might not necessarily win in terms of speed=
 but rather due to the simplicity of implementation and the overall mainten=
ance cost of the code. (I know that in programming, there is an entire camp=
 of immutability advocates who preach that their approach is the key remedy=
 for errors.)</p><p>I would support both paradigms, especially since it doe=
sn=E2=80=99t cost much.</p><p>A coroutine will own its internal context any=
way, and this context will be carried along with it, even across threads. H=
ow to use this context is up to the programmer to decide.=C2=A0

But at the same time, I will try to make the pattern you described fit seam=
lessly into this logic.</p><p>Ed.</p></div>

--0000000000003efff5062fa8a02c--