Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126650
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 08 Mar 2025 14:45:57 +0100
To: internals@lists.php.net
Message-ID: <9b7ab30f-5ed6-400d-b941-1291e9185286@app.fastmail.com>
In-Reply-To: <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com>
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>
 <74c4c726-63aa-44e0-84c9-840e13a65a4f@gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC
Content-Type: multipart/alternative;
 boundary=30e5857263944dbea60ad9ee2d19b75f
From: rob@bottled.codes ("Rob Landers")

--30e5857263944dbea60ad9ee2d19b75f
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 8, 2025, at 14:38, Daniil Gentili wrote:
>=20
> > 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 abl=
e to say "make sure the scheduler is started" and "block here until all =
child fibers are either concluded, detached, or cancelled".=20
>=20
> There's no need for such a construct, as the awaitAll function does pr=
ecisely what you describe, without the need to introduce the concept of =
a child fiber and the excessive limitation of an async block that severe=
ly limits concurrency.=20
>=20
> There is absolutely nothing wrong with the concept of a fiber without =
a parent, or a fiber that throws an exception (or a cancellation excepti=
on) out of the event loop.=20
>=20
> 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 su=
rfaces out of the event loop: it makes no sense to severely limit concur=
rency with an async block just to handle the edge case of an uncaught ex=
ception (which can be handled anyway with an event loop exception handle=
r).=20
>=20
> 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 b=
ad that must be limited and controlled, or else bad stuff will happen, w=
hen 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 en=
d of the world, and can be handled by other means, without limiting conc=
urrency.=20
>=20
> Regards,=20
> Daniil Gentili.

As far as I can tell, the entire reason we are talking about this is bec=
ause adding the event loop changes the behavior of existing code. So we =
cannot "just turn it on".

I haven't seen an explanation of why this is the case, but that's how we=
 got to this point. We need some way to "opt in" to turning on the event=
 loop.

=E2=80=94 Rob
--30e5857263944dbea60ad9ee2d19b75f
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sat, Mar 8, =
2025, at 14:38, Daniil Gentili wrote:<br></div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div><br></div><div><span dir=3D"ltr" style=3D"mar=
gin-top:0px;margin-bottom:0px;">&gt; The async block as I'm picturing it=
 has nothing to do with function colouring, it's about the outermost fun=
ction in an async stack being able to say "make sure the scheduler is st=
arted" and "block here until all child fibers are either concluded, deta=
ched, or cancelled".</span> <br></div><div> <br></div><div><span dir=3D"=
ltr" style=3D"margin-top:0px;margin-bottom:0px;">There's no need for suc=
h a construct, as the awaitAll function does precisely what you describe=
, without the need to introduce the concept of a child fiber and the exc=
essive limitation of an async block that severely limits concurrency.</s=
pan> <br></div><div> <br></div><div><span dir=3D"ltr" style=3D"margin-to=
p:0px;margin-bottom:0px;">There is absolutely nothing wrong with the con=
cept of a fiber without a parent, or a fiber that throws an exception (o=
r a cancellation exception) out of the event loop.</span> <br></div><div=
> <br></div><div><span dir=3D"ltr" style=3D"margin-top:0px;margin-bottom=
:0px;">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 fib=
er surfaces out of the event loop: it makes no sense to severely limit c=
oncurrency with an async block just to handle the edge case of an uncaug=
ht exception (which can be handled anyway with an event loop exception h=
andler).</span> <br></div><div> <br></div><div><span dir=3D"ltr" style=3D=
"margin-top:0px;margin-bottom:0px;">In general, I really don't like the =
concept of an async block the way it is presented here, because it impli=
es that concurrency is something bad that must be limited and controlled=
, or else bad stuff will happen, when in reality, a fiber throwing an ex=
ception (without anyone await()ing on the fiber handle, thus throwing ou=
t of the event loop) is not the end of the world, and can be handled by =
other means, without limiting concurrency.</span> <br></div><div> <br></=
div><div><span dir=3D"ltr" style=3D"margin-top:0px;margin-bottom:0px;">R=
egards,</span> <br></div><div><span dir=3D"ltr" style=3D"margin-top:0px;=
margin-bottom:0px;">Daniil Gentili.</span><br></div></blockquote><div><b=
r></div><div>As far as I can tell, the entire reason we are talking abou=
t this is because adding the event loop changes the behavior of existing=
 code. So we cannot "just turn it on".<br></div><div><br></div><div>I ha=
ven't seen an explanation of why this is the case, but that's how we got=
 to this point. We need some way to "opt in" to turning on the event loo=
p.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div><=
/body></html>
--30e5857263944dbea60ad9ee2d19b75f--