Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126659
Feedback-ID: id5114917:Fastmail
Date: Sat, 08 Mar 2025 20:56:12 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP True Async RFC
User-Agent: K-9 Mail for Android
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>
Message-ID: <77DC5F50-531D-49E8-8BE2-504A19CB5FFD@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 8 March 2025 13:38:30 GMT, Daniil Gentili <daniil=2Egentili@gmail=2Ecom=
> wrote:
>
>> The async block as I'm picturing it has nothing to do with function col=
ouring, it's about the outermost function in an async stack being able to s=
ay "make sure the scheduler is started" and "block here until all child fib=
ers are either concluded, detached, or cancelled"=2E
>
>There's no need for such a construct, as the awaitAll function does preci=
sely what you describe, without the need to introduce the concept of a chil=
d fiber and the excessive limitation of an async block that severely limits=
 concurrency=2E

No, it's not quite that either=2E The scenario I have in mind is a web / n=
etwork server spawning a fiber for each request, and wanting to know when e=
verything related to that request is finished, so that it can manage resour=
ces=2E

If we think of memory management as an analogy, awaitAll would be equivale=
nt to keeping track of all your memory pointers, and making sure to pass th=
em all to free before the end of the request=2E The construct we're discuss=
ing is like a garbage collection checkpoint, that ensures all memory alloca=
ted within that request has been freed, even if it wasn't tracked anywhere=
=2E

Written in ugly functions rather than concise and fail-safe syntax, it's s=
omething like:=20

$managedScope =3D new ManagedScope;
$previousScope =3D set_managed_scope( $managedScope );

spawn handle_request(); // inside here any number of fibers might be spawn=
ed

$managedScope->awaitAllChildFibers(); // we don't have the list of fibers =
here, so we can't use a plain awaitAll

set_managed_scope( $previousScope );
unset($managedScope);


It's certainly worth discussing whether this should be mandatory, default =
with an easy opt-out, or an equal-footing alternative to go-style unmanaged=
 coroutines=2E But the idea of automatically cleaning up resources at the e=
nd of a task (e=2Eg=2E an incoming request) is not new, and nor is arrangin=
g tasks in a tree structure=2E

I would also note that the concept of parent and child fibers is also usef=
ul for other proposed features, such as cascading cancellations, and having=
 environment-variable style inherited context data=2E None of those is *ess=
ential*, but unless there are major *implementation* concerns, they seem li=
ke useful features to offer the user=2E

Rowan Tommins
[IMSoP]