Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126663
Date: Sat, 8 Mar 2025 23:28:58 +0100 (GMT+01:00)
To: internals@lists.php.net
Message-ID: <bccf099c-55cf-4701-89eb-c26144696eac@gmail.com>
In-Reply-To: <510B8EF1-9D07-41A8-9EA0-7D99CF7BFC91@rwec.co.uk>
References: <CAMW7n8CM7oBfXCDsKtV4hTFs40UmLCU3183WjYE2exLNqKDWLQ@mail.gmail.com> <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>
Subject: Re: [PHP-DEV] PHP True Async RFC
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_12_218946989.1741472938659"
From: daniil.gentili@gmail.com (Daniil Gentili)

------=_Part_12_218946989.1741472938659
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

>> 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.
>
> Traditional PHP offers exactly this: the SAPI lifecycle tracks all file handles opened within a request, and closes them cleanly before reusing the thread or process for another request. Essentially what I'm proposing is a way to implement the same isolation in userland, by marking a checkpoint in the code.

Exposing this in userland offers an extremely dangerous footgun that will severely limit concurrency.

> As I've said repeatedly, it doesn't necessarily need to be a mandatory restriction, it can be a feature to help users write code without having to worry about *accidentally* leaving a background fiber running.

Even its use is optional, its 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.

Libraries can and should handle cleanup of running fibers by themselves, on their own terms, without externally imposed limitations.

It makes absolutely no sense, especially for a SAPI, to force all background fibers to stop after a request is finished.

It would force users to stop and restart all running fibers on each request, which is precisely the main argument for the use of worker mode: reducing overhead by keeping caches primed, sockets open and background loops running.

PHP itself explicitly offers an escape hatch around the "io {} block" of current SAPIs, in the form of persistent resources (and again, this is all for performance reasons).

Even ignoring performance considerations, as I said many times, 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).

Regards,
Daniil Gentili.

------=_Part_12_218946989.1741472938659
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>
  <span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt;&gt; 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><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt;</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt; Traditional PHP offers exactly this: the SAPI lifecycle tracks all file handles opened within a request, and closes them cleanly before reusing the thread or process for another request. Essentially what I'm proposing is a way to implement the same isolation in userland, by marking a checkpoint in the code.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Exposing this in userland offers an extremely dangerous footgun that will severely limit concurrency.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">&gt; As I've said repeatedly, it doesn't necessarily need to be a mandatory restriction, it can be a feature to help users write code without having to worry about *accidentally* leaving a background fiber running.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Even its use is optional, its 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;">Libraries can and should handle cleanup of running fibers by themselves, on their own terms, without externally imposed limitations.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">It makes absolutely no sense, especially for a SAPI, to force all background fibers to stop after a request is finished.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">It would force users to stop and restart all running fibers on each request, which is precisely the main argument for the use of worker mode: reducing overhead by keeping caches primed, sockets open and background loops running.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">PHP itself explicitly offers an escape hatch around the "io {} block" of current SAPIs, in the form of persistent resources (and again, this is all for performance reasons).</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Even ignoring performance considerations, as I said many times, 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;">Regards,</span>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Daniil Gentili.</span>
  <br>
 </body>
</html>
------=_Part_12_218946989.1741472938659--