Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126689
Feedback-ID: id5114917:Fastmail
Date: Mon, 10 Mar 2025 10:59:56 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP True Async RFC
User-Agent: K-9 Mail for Android
In-Reply-To: <def2620e-9a99-4a6f-b414-3c9f74232f5c@app.fastmail.com>
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com> <CAMW7n8CAbKRY9RZsJNSnehKVv8NNGtygocxc+zHBS4h9iRyUGA@mail.gmail.com> <1b6a5b3b-be9b-4e46-9cc6-b8b7f57b8494@app.fastmail.com> <CAMW7n8AumA6bYZ+7+c3rAEeYj0=35wgmohRbrJbH=fc=Ra0FJg@mail.gmail.com> <e65708a0-5130-4726-b405-e3185562d770@rwec.co.uk> <def2620e-9a99-4a6f-b414-3c9f74232f5c@app.fastmail.com>
Message-ID: <E273F908-DE5A-411B-BAA5-D72A04310EAA@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 10 March 2025 03:55:21 GMT, Larry Garfield <larry@garfieldtech=2Ecom> w=
rote:
>Support for nested blocks is absolutely mandatory, whatever else we do=2E=
  If you cannot nest one async block (scheduler instance, coroutine, whatev=
er it is) inside another, then basically no code can do anything async exce=
pt the top level framework=2E

To stretch the analogy slightly, this is like saying that no Linux program=
 could call fork() until containers were invented=2E That's quite obviously=
 not true; in a system without containers, the forked process is tracked by=
 the single global scheduler, and has a default relationship to its parent =
but also with other top-level processes=2E

Nested blocks are necessary *if* we want automatic resource management aro=
und user-selected parts of the program - which is close to being a tautolog=
y=2E If we don't provide them, we just need a defined start and end of the =
scheduler - and Edmond's current suggestion is that that could be an automa=
tic part of the process / thread lifecycle, and not visible to the user at =
all=2E


>This function needs to be possible, and work anywhere, regardless of whet=
her there's an "open" async session 5 stack calls up=2E
>
>function par_map(iterable $it, callable $c) {
>  $result =3D [];
>  async {
>    foreach ($it as $val) {
>      $result[] =3D $c($val);
>    }
>  }
>return $result;
>}

This looks to me like an example where you should not be creating an extra=
 context/nursery/whatever=2E A generic building block like map() should gen=
erally not impose resource restrictions on the code it's working with=2E In=
 fact as written there's no reason for this function to exist at all - if $=
c returns a Future, a normal array_map will return an array of Futures, and=
 can be composed with await_all, await_any, etc as necessary=2E

If an explicit nursery/context was required in order to use async features=
, you'd probably want instead to have a version of array_map which took one=
 as an extra parameter, and passed it to along to the callback:

function par_map(iterable $it, callable $c, AsyncContext $ctx) {
  $result =3D [];
  async {
    foreach ($it as $val) {
      $result[] =3D $c($val, $ctx);
    }
  }
return $result;
}

This is pretty much just coloured functions, but with uglier syntax, since=
 par_map itself isn't doing anything useful with the context, just passing =
along the one from an outer scope=2E An awful lot of functions would be lik=
e this; maybe FP experts would like it, authors of existing PHP code would =
absolutely hate it=2E


The place I see nested async{} blocks *potentially* being useful is to hav=
e a handful of key "firewalls" in the application, where any accidentally o=
rphaned coroutines can be automatically awaited before declaring a particul=
ar task "done"=2E But Daniil is probably right to ask for concrete use case=
s, and I have not used enough existing async code (in PHP or any other lang=
uage) to answer that confidently=2E

Rowan Tommins
[IMSoP]