Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126616
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> <CAMW7n8BGbjfCrPeiWO-mucYO3i8x=3XkcULXTjPbP7p3aV7rKg@mail.gmail.com>
 <779046a0-7c70-45a9-82c4-7c31c502cec2@rwec.co.uk> <CAMW7n8DXoKjXaZZ0HsSyA4k_+sY5iRyKhipwsVZvF2Ux+tFnww@mail.gmail.com>
In-Reply-To: <CAMW7n8DXoKjXaZZ0HsSyA4k_+sY5iRyKhipwsVZvF2Ux+tFnww@mail.gmail.com>
Date: Fri, 7 Mar 2025 10:48:38 +0200
Message-ID: <CAMW7n8BfpxOV5bd309T-A71mXO=1T8DoaO8c2__oNKUQ1-XrKw@mail.gmail.com>
Subject: Fwd: [PHP-DEV] PHP True Async RFC
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f8915b062fbcb05d"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000f8915b062fbcb05d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>  As far as I know, all current SAPIs follow one of two patterns:
>

It seems that my example, although taken from real life, is more of an
anti-pattern. Let's take a real example that is not an anti-pattern.

There is a B2B CRM built on services. Services are classes instantiated in
memory only once via DI, and all that. We process requests. Requests are
executed within a logical *Scope*. The scope depends on the *TOKEN* and
reflects the following entities:

   - *User Profile*
   - *Company Settings*

We have two implementation options:

   1. Pass the user profile and company settings to every method.
   2. Use some static variable to make the semantics shorter.

When the application runs in separate processes, there are no issues. What
do we do?

   1. Pass the UserProfile object into DI.
   2. Pass the CompanySettings object into DI.

Everyone is happy. If it=E2=80=99s a *long-running* process, everyone is tw=
ice as
happy because the already loaded services and resolved DI are reused
multiple times for handling requests. Memory copying is reduced, and for
fast requests, we get a nice performance boost. This is especially pleasant
for users with a good internet connection.

However, this model will not work if each request is processed in a
separate coroutine. There are two possible solutions:

   1. Pass the *"environment objects"* explicitly through function calls (*=
I=E2=80=99d
   like to see developers doing this and staying in a good mood*).
   2. Use something else.

There is also a *hybrid solution*, where the service method is called
through a *central manager*, the environment objects are stored in function
parameters but are injected not by the calling code but by the manager,
which extracts them from the current context. However, this approach
assumes that the service method *cannot* be called directly, so it is not
suitable as a *general solution*.

This approach will remain relevant *until PHP becomes a fully multitasking
language with parallel execution* (*if that ever happens*). However, there
is a strong argument against this.
In *Go*, you cannot implement an architecture with global contexts without
extra effort. But such solutions have a killer feature: *simplicity*. PHP
allows you to implement such architectures, which is one of its strengths.
By supporting this approach, we *enhance PHP=E2=80=99s ability* to move in =
this
direction.

This is the perspective in which I try to look at *RFC functions *as an
additional tool that should fit into *existing practices*.

> ```php function get_query_string_param(string $name): ?string {```

The solution you provided is similar to a real one, but I do not recommend
using it for the following reasons:

   1. Manual memory management. The coroutine completes, but the data
   remains. Who will clean it up?
   2. The need to write additional code to track memory usage. (call
   defer() or try/finally each time)
   3. The programmer might simply forget
   4. Async\Context is shared state, but not a global variable.

Async\Context is designed to *guarantee memory management*, which is a key
aspect for *long-running* applications. It *automatically releases object
references* when a coroutine completes. The programmer does not need to
write *extra code* with defer() for this.
Second point: Why Async\Context, Channel, and Future should not be just
external library objects.

There is a dilemma between a *"zoo of solutions"* and *"diversity"*.
Languages like *Rust, C, and C++* solve problems where diversity is more
important, even at the cost of dealing with a fragmented ecosystem.

Example: You need a *hash map function* optimized for *relocatable memory
blocks*, but such a thing doesn't exist out-of-the-box. The *more
diversity, the better*, as you can choose a solution tailored to your
unique case.

However, *PHP is not designed for such tasks*. If fundamental primitives in
PHP exist in *multiple competing libraries*, it becomes a nightmare.

   - It=E2=80=99s one thing if *standardized primitives* exist, and librari=
es
   provide alternatives on top of a shared contract.
   - It=E2=80=99s another if *every developer* has to reinvent the wheel fr=
om
   scratch.

If such primitives are not included in this or future RFCs, and instead are
left to chance, *it's better not to accept the RFC at all*.

This is the reason why the current RFC is large. It helps to see the bigger
picture. Once the general principles are agreed upon, we can split it into
parts (Incremental Design).

Such a plan.

Ed.

--000000000000f8915b062fbcb05d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><br><div =
dir=3D"ltr"><div dir=3D"ltr">&gt;<br>&gt;=C2=A0

As far as I know, all current SAPIs follow one of two patterns:<br>&gt;<div=
><br></div><div><p>It seems that my example, although taken from real life,=
 is more of an anti-pattern. Let&#39;s take a real example that is not an a=
nti-pattern.</p>
<p>There is a B2B CRM built on services. Services are classes instantiated =
in memory only once via DI, and all that. We process requests. Requests are=
 executed within a logical <strong>Scope</strong>. The scope depends on the=
 <strong>TOKEN</strong> and reflects the following entities:</p>
<ul>
<li><strong>User Profile</strong></li>
<li><strong>Company Settings</strong></li>
</ul>
<p>We have two implementation options:</p>
<ol>
<li>Pass the user profile and company settings to every method.</li>
<li>Use some static variable to make the semantics shorter.</li>
</ol>
<p>When the application runs in separate processes, there are no issues. Wh=
at do we do?</p>
<ol>
<li>Pass the <code>UserProfile</code> object into DI.</li>
<li>Pass the <code>CompanySettings</code> object into DI.</li>
</ol>
<p>Everyone is happy. If it=E2=80=99s a <strong>long-running</strong> proce=
ss, everyone is twice as happy because the already loaded services and reso=
lved DI are reused multiple times for handling requests. Memory copying is =
reduced, and for fast requests, we get a nice performance boost. This is es=
pecially pleasant for users with a good internet connection.</p>
<p>However, this model will not work if each request is processed in a sepa=
rate coroutine. There are two possible solutions:</p>
<ol>
<li>Pass the <strong>&quot;environment objects&quot;</strong> explicitly th=
rough function calls (<em>I=E2=80=99d like to see developers doing this and=
 staying in a good mood</em>).</li>
<li>Use something else.</li>
</ol>
<p>There is also a <strong>hybrid solution</strong>, where the service meth=
od is called through a <strong>central manager</strong>, the environment ob=
jects are stored in function parameters but are injected not by the calling=
 code but by the manager, which extracts them from the current context. How=
ever, this approach assumes that the service method <strong>cannot</strong>=
 be called directly, so it is not suitable as a <strong>general solution</s=
trong>.</p>
<p>This approach will remain relevant <strong>until PHP becomes a fully mul=
titasking language with parallel execution</strong> (<em>if that ever happe=
ns</em>). However, there is a strong argument against this.<br>
In <strong>Go</strong>, you cannot implement an architecture with global co=
ntexts without extra effort. But such solutions have a killer feature: <str=
ong>simplicity</strong>. PHP allows you to implement such architectures, wh=
ich is one of its strengths.<br>
By supporting this approach, we <strong>enhance PHP=E2=80=99s ability</stro=
ng> to move in this direction.</p>
<p>This is the perspective in which I try to look at <strong>RFC functions=
=C2=A0</strong>as an additional tool that should fit into <strong>existing =
practices</strong>.</p><p>&gt; ```php=C2=A0<span><span>function</span> <spa=
n>get_query_string_param</span>(<span><span>string</span> <span>$name</span=
></span>): ?<span>string</span> </span>{```</p><p>The solution you provided=
 is similar to a real one, but I do not recommend using it for the followin=
g reasons:</p><ol>
<li>Manual memory management. The coroutine completes, but the data remains=
. Who will clean it up?</li>
<li>The need to write additional code to track memory usage. (call defer() =
or try/finally each time)</li>
<li>The programmer might simply forget=C2=A0</li><li><code>Async\Context</c=
ode> is shared state, but not a global variable.=C2=A0=C2=A0</li>
</ol><p><code>Async\Context</code> is designed to <strong>guarantee memory =
management</strong>, which is a key aspect for <strong>long-running</strong=
> applications. It <strong>automatically releases object references</strong=
> when a coroutine completes. The programmer does not need to write <strong=
>extra code</strong> with <code>defer()</code> for this.</p><h3><span style=
=3D"font-weight:normal">Second point: Why Async\Context, Channel, and Futur=
e should not be just external library objects.</span></h3><p>There is a dil=
emma between a <strong>&quot;zoo of solutions&quot;</strong> and <strong>&q=
uot;diversity&quot;</strong>. Languages like <strong>Rust, C, and C++</stro=
ng> solve problems where diversity is more important, even at the cost of d=
ealing with a fragmented ecosystem.</p><p>Example: You need a <strong>hash =
map function</strong> optimized for <strong>relocatable memory blocks</stro=
ng>, but such a thing doesn&#39;t exist out-of-the-box. The <strong>more di=
versity, the better</strong>, as you can choose a solution tailored to your=
 unique case.</p><p>However, <strong>PHP is not designed for such tasks</st=
rong>. If fundamental primitives in PHP exist in <strong>multiple competing=
 libraries</strong>, it becomes a nightmare.</p><ul>
<li>It=E2=80=99s one thing if <strong>standardized primitives</strong> exis=
t, and libraries provide alternatives on top of a shared contract.</li>
<li>It=E2=80=99s another if <strong>every developer</strong> has to reinven=
t the wheel from scratch.</li>
</ul><p>




</p><p>If such primitives are not included in this or future RFCs, and inst=
ead are left to chance, <strong>it&#39;s better not to accept the RFC at al=
l</strong>.</p><p>This is the reason why the current RFC is large. It helps=
 to see the bigger picture. Once the general principles are agreed upon, we=
 can split it into parts (Incremental Design).=C2=A0=C2=A0=C2=A0</p><p>Such=
 a plan.</p><p>Ed.</p></div></div>
</div>
</div></div>

--000000000000f8915b062fbcb05d--