Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128844
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 16 Oct 2025 04:19:00 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: internals@lists.php.net
Message-ID: <2b9fd3ec-50ca-41e4-985a-274f886df8b3@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8BfP7h5rpDrjigu0oWK4Z+aRaqGjgzEFS_mDXRhq19vQQ@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <bcd8253c-04f3-4046-b51f-2e387e215f6d@app.fastmail.com>
 <CAMW7n8BfP7h5rpDrjigu0oWK4Z+aRaqGjgzEFS_mDXRhq19vQQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=1bb25fdd8ee242988138cdf73072318a
From: rob@bottled.codes ("Rob Landers")

--1bb25fdd8ee242988138cdf73072318a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Oct 15, 2025, at 09:53, Edmond Dantes wrote:
> Hello.
>=20
> > Why doesn=E2=80=99t scope implement Awaitable?
>=20
> Let=E2=80=99s say there=E2=80=99s a programmer named *John* who is wri=
ting a library,
> and he has a function that calls an external handler.
> Programmer *Robert* wrote the `externalHandler`.
>=20
> ```php
> function processData(string $url, callable $externalHandler): void
> {
>    ...
>     $externalHandler($result);
> }
> ```
>=20
> John knows which contracts are inside processData, but he knows
> nothing about `$externalHandler`.
> From the perspective of `processData`, `$externalHandler` acts as a
> **black box**.
> If John uses `await()` on that black box, it may lead to an infinite w=
ait.
>=20
> There are two solutions to this problem:
>=20
> 1. Delegate full responsibility for the program=E2=80=99s behavior to
> *Robert*, meaning to `$externalHandler`
> 2. Establish a limiting contract
>=20
> Therefore, if a `Scope` needs to be awaited, it can only be done
> together with a cancellation token.
>=20
> In real-world scenarios, awaiting a `Scope` during normal execution
> makes no sense, because you have a `cancellation policy`.
> This means that at any necessary moment you can dispose() the `Scope`
> and thus interrupt the execution of tasks inside the black box.
>=20
> For the `TaskGroup` pattern, which exists in the third version of the
> RFC, awaiting is a relatively safe operation, because in this case we
> assume that the code is written by someone who has direct access to
> the agreements and bears full responsibility for any errors.
>=20
> So, `Scope` is intended for components where responsibility is shared
> between different programmers, while `TaskGroup` should be used when
> working with a clearly defined set of coroutines.
>=20

I don=E2=80=99t get it. What does different programmers working on a pro=
gram have to do with whether or not scopes implements Awaitable? Scope h=
as an await method, it should be Awaitable. await() takes a cancellation=
 and thus anything Awaitable can be cancelled at any time. I don=E2=80=99=
t see why scope is special in that regard.

> If John uses `await()` on that black box, it may lead to an infinite w=
ait.

This is true of any software or code. Knowing whether or not something w=
ill ever complete is called The Halting Problem. It is unsolvable, in th=
e general sense. You can await() a read of an infinite file, or a remote=
 file that will take 5y to read because it is being read at 1 bps. Your =
clock can fry on your motherboard, preventing timeouts from ever firing.=
 Your disk can die mid-read, preventing it from ever sending you any dat=
a. There is so much that can go wrong. To say that something that has an=
 await method isn=E2=80=99t Awaitable because it may never return is tru=
e for ALL Awaitable tasks as well. It isn=E2=80=99t special.=20

=E2=80=94 Rob
--1bb25fdd8ee242988138cdf73072318a
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Wed, Oct 15, 2025, at 09:53, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hello.</div><div=
><br></div><div>&gt; Why doesn=E2=80=99t scope implement Awaitable?</div=
><div><br></div><div>Let=E2=80=99s say there=E2=80=99s a programmer name=
d *John* who is writing a library,</div><div>and he has a function that =
calls an external handler.</div><div>Programmer *Robert* wrote the `exte=
rnalHandler`.</div><div><br></div><div>```php</div><div>function process=
Data(string $url, callable $externalHandler): void</div><div>{</div><div=
>&nbsp;&nbsp; ...</div><div>&nbsp;&nbsp;&nbsp; $externalHandler($result)=
;</div><div>}</div><div>```</div><div><br></div><div>John knows which co=
ntracts are inside processData, but he knows</div><div>nothing about `$e=
xternalHandler`.</div><div>From the perspective of `processData`, `$exte=
rnalHandler` acts as a</div><div>**black box**.</div><div>If John uses `=
await()` on that black box, it may lead to an infinite wait.</div><div><=
br></div><div>There are two solutions to this problem:</div><div><br></d=
iv><div>1. Delegate full responsibility for the program=E2=80=99s behavi=
or to</div><div>*Robert*, meaning to `$externalHandler`</div><div>2. Est=
ablish a limiting contract</div><div><br></div><div>Therefore, if a `Sco=
pe` needs to be awaited, it can only be done</div><div>together with a c=
ancellation token.</div><div><br></div><div>In real-world scenarios, awa=
iting a `Scope` during normal execution</div><div>makes no sense, becaus=
e you have a `cancellation policy`.</div><div>This means that at any nec=
essary moment you can dispose() the `Scope`</div><div>and thus interrupt=
 the execution of tasks inside the black box.</div><div><br></div><div>F=
or the `TaskGroup` pattern, which exists in the third version of the</di=
v><div>RFC, awaiting is a relatively safe operation, because in this cas=
e we</div><div>assume that the code is written by someone who has direct=
 access to</div><div>the agreements and bears full responsibility for an=
y errors.</div><div><br></div><div>So, `Scope` is intended for component=
s where responsibility is shared</div><div>between different programmers=
, while `TaskGroup` should be used when</div><div>working with a clearly=
 defined set of coroutines.</div><div><br></div></blockquote><div><br></=
div><div>I don=E2=80=99t get it. What does different programmers working=
 on a program have to do with whether or not scopes implements Awaitable=
? Scope has an await method, it should be Awaitable. await() takes a can=
cellation and thus anything Awaitable can be cancelled at any time. I do=
n=E2=80=99t see why scope is special in that regard.</div><div><br></div=
><blockquote type=3D"cite"><div>If John uses `await()` on that black box=
, it may lead to an infinite wait.</div></blockquote><div><br></div><div=
>This is true of any software or code. Knowing whether or not something =
will ever complete is called The Halting Problem. It is unsolvable, in t=
he general sense. You can await() a read of an infinite file, or a remot=
e file that will take 5y to read because it is being read at 1 bps. Your=
 clock can fry on your motherboard, preventing timeouts from ever firing=
. Your disk can die mid-read, preventing it from ever sending you any da=
ta. There is so much that can go wrong. To say that something that has a=
n await method isn=E2=80=99t Awaitable because it may never return is tr=
ue for ALL Awaitable tasks as well. It isn=E2=80=99t special.&nbsp;</div=
><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></htm=
l>
--1bb25fdd8ee242988138cdf73072318a--