Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126661
Date: Sat, 8 Mar 2025 23:06:48 +0100 (GMT+01:00)
To: internals@lists.php.net
Message-ID: <86091fdf-d1bf-489a-b5e2-5c80484f2181@gmail.com>
In-Reply-To: <CAMW7n8D3Jv9w+em4=Vxqi__XB2KZcC0q7B2zKBxonuv7D=c1Rw@mail.gmail.com>
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> <9b7ab30f-5ed6-400d-b941-1291e9185286@app.fastmail.com> <9a2e81e8-3534-455b-879a-5a45c85b3ba7@gmail.com> <de94a01a-ccee-423d-bd47-3e6257adfe7d@gmail.com> <CAMW7n8D3Jv9w+em4=Vxqi__XB2KZcC0q7B2zKBxonuv7D=c1Rw@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_6_193608181.1741471608611"
From: daniil.gentili@gmail.com (Daniil Gentili)

------=_Part_6_193608181.1741471608611
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>>=C2=A0 Crippling async PHP with async blocks just because some libraries =
aren't ready for concurrency now, means crippling the future of async php.
>>
> How can calling a single function have such a destructive impact on the f=
uture of PHP?=C2=A0


Very simple: to make an analogy, it's like saying PHP should have an io {} =
block, that makes sure all file resources opened within (even internally, 1=
0 stack levels deep into 3 libraries, whose instances are all used after th=
e io {} block) are closed when exiting.

The async {} block is a footgun that tries to meddle with what must be an i=
nternal implementation detail of the libraries you're using.

Even if they were optional, their presence in the language could lead libra=
ry developers to reduce concurrency in order to allow calls from async bloc=
ks, (i.e. don't spawn any background fiber in a method call because it migh=
t be called from an async {} block) which is what I meant by crippling asyn=
c PHP.

If the async {} block were to ignore *referenced* spawned fiber handles, it=
 would still be just as bad: sometimes one really just needs to spawn a bac=
kground fiber to do a one-off background task, without caring about the res=
ult.

I.e. the spawned logic may also contain a catch (\Throwable) block with err=
or handling, making collection of references into an array to awaitAll in _=
_destruct (just because someone might invoke the code from an async {} bloc=
k!) pointless and an overcomplication.

Amphp's approach of an event loop exception handler is, I believe, the perf=
ect uncaught exception handling solution.

(Also note that amphp also provides an escape hatch even for the exception =
handler: a Future::ignore() method that prevents uncaught and non-awaited e=
xceptions from bubbling out into the exception handler).

Regards,
Daniil Gentili.

------=_Part_6_193608181.1741471608611
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
 <head>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
 </head>
 <body>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt;&gt;&nbsp; Crippling async PHP with async blocks just because some libraries aren't ready for concurrency now, means crippling the future of async php.</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt;&gt;</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt; How can calling a single function have such a destructive impact on the future of PHP?&nbsp;</span>
  <br>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Very simple: to make an analogy, it's like saying PHP should have an io {} block, that makes sure all file resources opened within (even internally, 10 stack levels deep into 3 libraries, whose instances are all used after the io {} block) are closed when exiting.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">The async {} block is a footgun that tries to meddle with what must be an internal implementation detail of the libraries you're using.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Even if they were optional, their presence in the language could lead library developers to reduce concurrency in order to allow calls from async blocks, (i.e. don't spawn any background fiber in a method call because it might be called from an async {} block) which is what I meant by crippling async PHP.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">If the async {} block were to ignore *referenced* spawned fiber handles, it would still be just as bad: sometimes one really just needs to spawn a background fiber to do a one-off background task, without caring about the result.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">I.e. the spawned logic may also contain a catch (\Throwable) block with error handling, making collection of references into an array to awaitAll in __destruct (just because someone might invoke the code from an async {} block!) pointless and an overcomplication.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Amphp's approach of an event loop exception handler is, I believe, the perfect uncaught exception handling solution.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">(Also note that amphp also provides an escape hatch even for the exception handler: a Future::ignore() method that prevents uncaught and non-awaited exceptions from bubbling out into the exception handler).</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Regards,</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Daniil Gentili.</span>
  <br>
 </body>
</html>
------=_Part_6_193608181.1741471608611--