Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126601
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>
 <23e162f6-54b0-4564-9d79-7b3bdc3d1ab5@rwec.co.uk> <CAMW7n8A_KM6W0NHk_Ypd2PGdJZbi0quxwGvM27pf-U-YOe-RGw@mail.gmail.com>
 <36cee7e3-2ef8-4f96-a72e-e67a99e5f9bb@rwec.co.uk>
In-Reply-To: <36cee7e3-2ef8-4f96-a72e-e67a99e5f9bb@rwec.co.uk>
Date: Thu, 6 Mar 2025 13:31:22 +0200
Message-ID: <CAMW7n8BGbjfCrPeiWO-mucYO3i8x=3XkcULXTjPbP7p3aV7rKg@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="00000000000026c263062faad9fd"
From: edmond.ht@gmail.com (Edmond Dantes)

--00000000000026c263062faad9fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  In a syntax-and-semantics approach, we only need to describe the things
people actually need.

There is no doubt that syntax provides the programmer with a clear tool for
expressing intent.

> In the same way, do we actually need to design what an "async context"
looks like to the user?

Its implementation is more about deciding which paradigms we want to
support.

If we want to support global services that require local state within a
coroutine, then they need a context. If there are no global "impure"
services (i.e., those maintaining state within a coroutine), then a context
may not be necessary. The first paradigm is not applicable to pure
multitasking=E2=80=94almost all programming languages (as far as I know) ha=
ve
abandoned it in favor of ownership/memory passing. However, in PHP, it is
popular.

For example, PHP has functions for working with HTTP. One of them writes
the last received headers into a "global" variable, and another function
allows retrieving them. This is where a context is needed. Or, for
instance, when a request is made inside a coroutine, the service that
handles socket interactions under the hood must:

   1. Retrieve a socket from the connection pool.
   2. Place the socket in the coroutine=E2=80=99s context for as long as it=
 is
   needed.

However, this same scenario could be implemented more elegantly if PHP code
explicitly used an object like "Connection" or "Transaction" and retrieved
it from the pool. In that case, a context would not be needed.

Thus, the only question is: do we need to maintain state between
function/method calls within a coroutine?

> Do we actually want the user to be able to have access to two (nested)
async contexts at once, and choose which one to spawn a task into?

If we discard the Go model, where the programmer decides what to do and
which foot to shoot themselves in, and instead use parent-child coroutines,
then such a function breaks this rule. This means it should not exist, as
its presence increases system complexity. However, in the parent-child
model, there is a case where a coroutine needs to be created in a different
context.

For example:

   - A request to reset a password arrives at the server.
   - The API creates a coroutine in a separate context from the request to
   send an email.
   - The API returns a 201 response.

In this case, a special API is needed to accomplish this. The downside of
any strict semantics is the presence of exceptional cases. However, such
cases should be rare. If they are not, then the parent-child model is not
suitable.

To resolve this issue, we need to know the opinions of framework
maintainers. They should say either: *Yes, this approach will reduce the
amount of code*, or *No, it will increase the codebase*, or *We don't care,
do as you like* :)

--00000000000026c263062faad9fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">&gt;=C2=A0

In a syntax-and-semantics approach, we only need to describe the things peo=
ple actually need.<div><br></div><div>There is no doubt that syntax provide=
s the programmer with a clear tool for expressing intent.<br><br></div><div=
>&gt; In the same way, do we actually need to design what an &quot;async co=
ntext&quot; looks like to the user?</div><div><br></div><div>Its implementa=
tion is more about deciding which paradigms we want to support.</div><div><=
p>If we want to support global services that require local state within a c=
oroutine, then they need a context. If there are no global &quot;impure&quo=
t; services (i.e., those maintaining state within a coroutine), then a cont=
ext may not be necessary. The first paradigm is not applicable to pure mult=
itasking=E2=80=94almost all programming languages (as far as I know) have a=
bandoned it in favor of ownership/memory passing. However, in PHP, it is po=
pular.</p><p>For example, PHP has functions for working with HTTP. One of t=
hem writes the last received headers into a &quot;global&quot; variable, an=
d another function allows retrieving them. This is where a context is neede=
d. Or, for instance, when a request is made inside a coroutine, the service=
 that handles socket interactions under the hood must:</p><ol><li>Retrieve =
a socket from the connection pool.</li><li>Place the socket in the coroutin=
e=E2=80=99s context for as long as it is needed.</li></ol><p>However, this =
same scenario could be implemented more elegantly if PHP code explicitly us=
ed an object like &quot;Connection&quot; or &quot;Transaction&quot; and ret=
rieved it from the pool. In that case, a context would not be needed.</p><p=
>Thus, the only question is: do we need to maintain state between function/=
method calls within a coroutine?</p><p>&gt; Do we actually want the user to=
 be able to have access to two (nested) async contexts at once, and choose =
which one to spawn a task into?</p><p>If we discard the Go model, where the=
 programmer decides what to do and which foot to shoot themselves in, and i=
nstead use parent-child coroutines, then such a function breaks this rule. =
This means it should not exist, as its presence increases system complexity=
. However, in the parent-child model, there is a case where a coroutine nee=
ds to be created in a different context.</p><p>For example:</p><ul><li>A re=
quest to reset a password arrives at the server.</li><li>The API creates a =
coroutine in a separate context from the request to send an email.</li><li>=
The API returns a 201 response.</li></ul><p>In this case, a special API is =
needed to accomplish this. The downside of any strict semantics is the pres=
ence of exceptional cases. However, such cases should be rare. If they are =
not, then the parent-child model is not suitable.</p><p>To resolve this iss=
ue, we need to know the opinions of framework maintainers. They should say =
either: <em>Yes, this approach will reduce the amount of code</em>, or <em>=
No, it will increase the codebase</em>, or <em>We don&#39;t care, do as you=
 like</em> :)=C2=A0=C2=A0</p></div></div></div>

--00000000000026c263062faad9fd--