Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126820
Feedback-ID: id5114917:Fastmail
Date: Tue, 18 Mar 2025 07:59:58 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
User-Agent: K-9 Mail for Android
In-Reply-To: <fdeeec46-55c0-409e-a230-f04c3af23464@app.fastmail.com>
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com> <fdeeec46-55c0-409e-a230-f04c3af23464@app.fastmail.com>
Message-ID: <D7359854-A74F-47B3-8C49-AE1F9C275E58@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 18 March 2025 05:59:07 GMT, Larry Garfield <larry@garfieldtech=2Ecom> w=
rote:

>My biggest issue, though, is that I honestly can't tell what the mental m=
odel is supposed to be=2E  The RFC goes into detail about three different a=
sync models=2E  Are those standard terms you're borrowing from elsewhere, o=
r your own creation?  If the former, please include citations=2E  I cannot =
really tell which one the "playpen" model would fit into=2E  I=2E=2E=2E thi=
nk bottom up, but I'm not sure=2E  Moreover, I then cannot tell which of th=
ose models is in use in the RFC=2E  There's a passing reference to it being=
 bottom up, I think, but it certainly looks like the No Limit model=2E  The=
re's a section called structured concurrency, but what it describes doesn't=
 look a thing like the playpen-definition of structured concurrency, which =
as noted is my preference=2E  It's not clear why the various positives and =
negatives are there; it's just presented as though self-evident=2E  Why doe=
s bottom up lead to high memory usage, for instance?  That's not clear to m=
e=2E  So really=2E=2E=2E I have no idea how to think about any of it=2E


I had a very different reaction to that section=2E I do agree that some ci=
tations and links to prior art would be good - I mentioned in my first emai=
l that the "actor model" is mentioned in passing without ever being defined=
 - but in general, I  thought this summary was very succinct:

> -  No limitation=2E Coroutines are not limited in their lifetime and run=
 as long as needed=2E
> - Top-down limitation: Parent coroutines limit the lifetime of their chi=
ldren
> - Bottom-up limitation: Child coroutines extend the execution time of th=
eir parents

Since you've described playpens as having an implicit "await all", they're=
 bottom-up: the parent lasts as long as its longest child=2E Top-down would=
 be the same thing, but with an implicit "cancel all" instead=2E


>Broadly speaking, I can think of three usage patterns for async in PHP (s=
peaking, again, as someone who doesn't have a lot of async experience, so I=
 may be missing some):
>
>1=2E Fan-out=2E  This is the "fetch all these URLs at once" type use case=
, which in most cases could be wrapped up into a para_map() function=2E  (W=
hich is exactly what Rust does=2E)
>2=2E Request handlers, for persistent-process servers=2E  Would also appl=
y for a queue worker=2E
>3=2E Throw it over the wall=2E  This would be the logging example, or sen=
ding an email on some trigger, etc=2E  Importantly, these are cases where t=
here is no result needed from the sub-routine=2E


I agree that using these as key examples would be good=2E



>// Creates an async scope, in which you can create coroutines=2E
>async {


The problem with using examples like this is that it's not clear what happ=
ens further down the stack - are you not allowed to spawn/start/whatever an=
ything? Does it get started in the "inherited" scope?

You've also done exactly what you complained the RFC did and provided a co=
mpletely artificial example - which of the key use cases you identified is =
this version of scope trying to solve?

I actually think what you're describing is very similar to the RFC, just w=
ith different syntax; but your examples are different, so you're talking pa=
st each other a bit=2E



>I honestly cannot see a use case at this point for starting coroutines in=
 arbitrary scopes=2E


The way I picture it is mostly about choosing between creating a child wit=
hin a narrow scope you've just opened, vs creating a sibling in the scope c=
reated somewhere up the stack=2E

The "request handler" use case could easily benefit from a "pseudo-global"=
 scope for each request - i e=2E "tie this to the current request, but not =
to anything else that's started a scope in between"=2E

There were also some concrete examples given in the previous thread of exp=
licitly managing a context/scope/playpen in a library=2E


Rowan Tommins
[IMSoP]