Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126666
Date: Sun, 9 Mar 2025 00:22:08 +0100 (GMT+01:00)
To: internals@lists.php.net
Message-ID: <4690cff0-7a48-4fe0-8310-688be253f976@gmail.com>
In-Reply-To: <bccf099c-55cf-4701-89eb-c26144696eac@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> <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>
Subject: Re: [PHP-DEV] PHP True Async RFC
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_5_248741874.1741476128356"
From: daniil.gentili@gmail.com (Daniil Gentili)

------=_Part_5_248741874.1741476128356
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


> Offering this tool to userland is a major footgun that will either backfire spectacularly (breaking existing and new async libraries by endlessly awaiting upon background fibers when exiting an async {} block haphazardly used by a newbie, or even worse force library developers to reduce concurrency, killing async PHP just because users can use async {} blocks), or simply not get used at all (because the main SAPI usecase listed explicitly does NOT need purity).

Some extra points:

1) The naming of "async {}" is also very misleading, as it does the opposite of making things async, if anything it should be called "wait_all {}"

2) Again, what are waiting for? A fiber spawned by a library we called 10 levels deep in the stack, that exits only when the container object is destroyed (outside of the wait_all block, thus causing an endless hang)? No one should care or be able to control what must remain an internal implementation detail of invoked libraries, adding a wait_all block will only break stuff.

3) If we did want to wait for all fibers spawned by a method call, nothing is preventing the caller from returning an array of futures for spawned fibers that we can await.

The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of async libraries, because the only feature it offers (that isn't already offered by awaitAll) is one that controls internal implementation details of libraries invoked within the block.

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.

It is, imo, a MAJOR FOOTGUN, and should not be even considered for implementation.

Regards,
Daniil Gentili.

------=_Part_5_248741874.1741476128356
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; Offering this tool to userland is a major footgun that will either backfire spectacularly (breaking existing and new async libraries by endlessly awaiting upon background fibers when exiting an async {} block haphazardly used by a newbie, or even worse force library developers to reduce concurrency, killing async PHP just because users can use async {} blocks), or simply not get used at all (because the main SAPI usecase listed explicitly does NOT need purity).</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Some extra points:</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">1) The naming of "async {}" is also very misleading, as it does the opposite of making things async, if anything it should be called "wait_all {}"</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">2) Again, what are waiting for? A fiber spawned by a library we called 10 levels deep in the stack, that exits only when the container object is destroyed (outside of the wait_all block, thus causing an endless hang)? No one should care or be able to control what must remain an internal implementation detail of invoked libraries, adding a wait_all block will only break stuff.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">3) If we did want to wait for all fibers spawned by a method call, nothing is preventing the caller from returning an array of futures for spawned fibers that we can await.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">The wait_all block is EXPLICITLY DESIGNED to meddle with the internals of async libraries, because the only feature it offers (that isn't already offered by awaitAll) is one that controls internal implementation details of libraries invoked within the block.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">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.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">It is, imo, a MAJOR FOOTGUN, and should not be even considered for implementation.</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_5_248741874.1741476128356--