Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126668
Precedence: bulk
MIME-Version: 1.0
References: <78a03dd0-fd4a-4f4a-ad8a-37e5704f06fc@app.fastmail.com>
 <CAMW7n8C-Z18MKhyDX2+ofg70cRbwWOk=YWDAZpKtfLZsFVVRng@mail.gmail.com>
 <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>
In-Reply-To: <4690cff0-7a48-4fe0-8310-688be253f976@gmail.com>
Date: Sun, 9 Mar 2025 10:42:30 +0200
Message-ID: <CAMW7n8DTVPkA0qk30TCf1+L3Rmooyt5eEMco+=ds_TX3fEXn-Q@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
To: Daniil Gentili <daniil.gentili@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a93969062fe4d684"
From: edmond.ht@gmail.com (Edmond Dantes)

--000000000000a93969062fe4d684
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of
async libraries,
>

How exactly does it interfere with the implementation of asynchronous
libraries?
Especially considering that these libraries operate at the User-land level?
It=E2=80=99s a contract. No more. No less.

>
>  Libraries can full well handle cleanup of fibers in __destruct by
themselves, without a wait_all block forcing them to reduce concurrency
whenever the caller pleases.
>
Fiber is a final class, so there can be no destructors here. Even if you
create a "Coroutine" class and allow defining a destructor, the result will
be overly verbose code. I and many other developers have tested this.
And the creators of AMPHP did not take this approach. Go doesn=E2=80=99t ha=
ve it
either. This is not a coincidence.

>
>  It is, imo, a MAJOR FOOTGUN, and should not be even considered for
implementation.
>

Why exactly is this a FOOTGUN?

   - Does this block lead to new violations of language integrity?
   - Does this block increase the likelihood of errors?

A FOOTGUN is something that significantly breaks the language and pushes
developers toward writing bad code. This is a rather serious flaw.

--000000000000a93969062fe4d684
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;<br>&gt;=C2=A0<span style=3D"background-color:rgb(242,=
242,242);color:rgb(51,51,51);font-family:&quot;Fira Mono&quot;,monospace;fo=
nt-size:14px">The wait_all block is EXPLICITLY DESIGNED to meddle with the =
internals of async libraries,</span><br>&gt;<div><br></div><div>How exactly=
 does it interfere with the implementation of asynchronous libraries?=C2=A0=
</div><div>Especially considering that these libraries operate at the User-=
land level? It=E2=80=99s a contract. No more. No less.

</div><div><br></div><div>&gt;<br>&gt;=C2=A0

Libraries can full well handle cleanup of fibers in __destruct by themselve=
s, without a wait_all block forcing them to reduce concurrency whenever the=
 caller pleases.<br>&gt;<br>Fiber is a <code>final</code> class, so there c=
an be no destructors here. Even if you create a &quot;Coroutine&quot; class=
 and allow defining a destructor, the result will be overly verbose code. I=
 and many other developers have tested this.</div><div>

And the creators of AMPHP did not take this approach. Go doesn=E2=80=99t ha=
ve it either. This is not a coincidence.=C2=A0</div><div><br></div><div>&gt=
;<br>&gt;=C2=A0

It is, imo, a MAJOR FOOTGUN, and should not be even considered for implemen=
tation.<br>&gt;=C2=A0 =C2=A0</div><div><br></div><div><p>Why exactly is thi=
s a FOOTGUN?</p>
<ul>
<li>Does this block lead to new violations of language integrity?</li>
<li>Does this block increase the likelihood of errors?</li>
</ul>
<p>A FOOTGUN is something that significantly breaks the language and pushes=
 developers toward writing bad code. This is a rather serious flaw.</p></di=
v></div>

--000000000000a93969062fe4d684--