Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126649
Date: Sat, 8 Mar 2025 14:38:30 +0100 (GMT+01:00)
To: internals@lists.php.net
Message-ID: <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com>
In-Reply-To: <D73BCCC4-3547-45B4-84AD-A5FD6569D43C@rwec.co.uk>
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> <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>
Subject: Re: [PHP-DEV] PHP True Async RFC
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_6_250549312.1741441110823"
From: daniil.gentili@gmail.com (Daniil Gentili)

------=_Part_6_250549312.1741441110823
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


> The async block as I'm picturing it has nothing to do with function colouring, it's about the outermost function in an async stack being able to say "make sure the scheduler is started" and "block here until all child fibers are either concluded, detached, or cancelled".

There's no need for such a construct, as the awaitAll function does precisely what you describe, without the need to introduce the concept of a child fiber and the excessive limitation of an async block that severely limits concurrency.

There is absolutely nothing wrong with the concept of a fiber without a parent, or a fiber that throws an exception (or a cancellation exception) out of the event loop.

A panic in a golang fiber surfaces out of the event loop (unless it is catched with a recover), just like an uncatched exception in a fiber surfaces out of the event loop: it makes no sense to severely limit concurrency with an async block just to handle the edge case of an uncaught exception (which can be handled anyway with an event loop exception handler).

In general, I really don't like the concept of an async block the way it is presented here, because it implies that concurrency is something bad that must be limited and controlled, or else bad stuff will happen, when in reality, a fiber throwing an exception (without anyone await()ing on the fiber handle, thus throwing out of the event loop) is not the end of the world, and can be handled by other means, without limiting concurrency.

Regards,
Daniil Gentili.

------=_Part_6_250549312.1741441110823
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; The async block as I'm picturing it has nothing to do with function colouring, it's about the outermost function in an async stack being able to say "make sure the scheduler is started" and "block here until all child fibers are either concluded, detached, or cancelled".</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">There's no need for such a construct, as the awaitAll function does precisely what you describe, without the need to introduce the concept of a child fiber and the excessive limitation of an async block that severely limits concurrency.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">There is absolutely nothing wrong with the concept of a fiber without a parent, or a fiber that throws an exception (or a cancellation exception) out of the event loop.</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">A panic in a golang fiber surfaces out of the event loop (unless it is catched with a recover), just like an uncatched exception in a fiber surfaces out of the event loop: it makes no sense to severely limit concurrency with an async block just to handle the edge case of an uncaught exception (which can be handled anyway with an event loop exception handler).</span>
  <br>
  <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">In general, I really don't like the concept of an async block the way it is presented here, because it implies that concurrency is something bad that must be limited and controlled, or else bad stuff will happen, when in reality, a fiber throwing an exception (without anyone await()ing on the fiber handle, thus throwing out of the event loop) is not the end of the world, and can be handled by other means, without limiting concurrency.</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_250549312.1741441110823--