Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126629
Precedence: bulk
MIME-Version: 1.0
References: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
In-Reply-To: <CAMW7n8AJckEDzhGv9BdjNhq8zAdCqb4HsVr56vGi+izw50X6Dg@mail.gmail.com>
Date: Sat, 8 Mar 2025 09:05:37 +0200
Message-ID: <CAMW7n8CAbKRY9RZsJNSnehKVv8NNGtygocxc+zHBS4h9iRyUGA@mail.gmail.com>
Subject: [PHP-DEV] Re: PHP True Async RFC
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005fa2d3062fcf5eea"
From: edmond.ht@gmail.com (Edmond Dantes)

--0000000000005fa2d3062fcf5eea
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello all.

A few thoughts aloud about the emerging picture.

### Entry point into the asynchronous context
Most likely, it should be implemented as a separate function (I haven't
come up with a good name yet), with a unique name to ensure its behavior
does not overlap with other operators. It has a unique property: it waits
for the full completion of the event loop and the Scheduler.

Inside the asynchronous context, `Fiber` is prohibited, and conversely,
inside a `Fiber`, the asynchronous context is prohibited.

### The `async` operator
The `async` (or *spawn*?) operator can be used as a shorthand for spawning
a coroutine:

```php
function my($param) {}

// Operator used as a function call
async my(1);
or
spawn my(1);

// Operator used as a closure
async {
    code
};

// Since it's a closure, the `use` statement can be used without
restrictions
async use($var) {
    code
};

// Returns a coroutine class instance
$x =3D async use($var) {
    code
};
```

### The `await` operator
The `await` operator can be added to `async`, allowing explicit suspension
of execution to wait for a result:

```php
$x =3D await async use($var) {
    code
};
```

## Context Manipulations
I didn't like functions like `overrideContext`. They allow changing the
context multiple times at any point in a function, which can lead to errors
that are difficult to debug. This is a really bad approach. It is much
better to declare the context at the time of coroutine invocation. With
syntax, it might look like this:

```php
async in $context use() {}
async in $context myFun()
async in $context->with("key", value) myFun()
or
spawn in $context ...
```

## Thread
The syntax spawn in/async in can be used not only in standard cases.

```php
$coro =3D async in new ThreadContext() use($channel) {
    while() {}
};

// This expression is also valid
$coro =3D async in new $threadPool->borrowContext() use($channel) {
    while() {}
};
```

It is worth noting that $threadPool itself may be provided by an extension
and not be a part of PHP.

## Unrelated Coroutines
An additional way is needed to create a coroutine that is not bound to a
parent.
It's worth considering how to make this as clear and convenient as possible=
.
Maybe as keyword:

```php
async unbound ...
```

Of course, an `async child` modifier can be used. This is the inverse
implementation, but I think it will not be used often. Making `unbound` a
separate method is not very appealing at the moment because a programmer
might forget to call it. They could forget the word `unbound`, and even
more so a whole method.

## Context Operations
```php
await $context; // Waits for all coroutines in the context
$context.cancel(); // Cancels everything within the context
```

## Flow

I want to thank all the participants in the discussion.
Thanks to your ideas, questions, and examples. A week ago, answering this
question would have been impossible.

If we add exception handling and graceful shutdown, and remove the new
syntax by replacing it with an equivalent of 2-3 functions, we will get a
fairly cohesive RFC that describes the high-level part without unnecessary
details. Channels and even Future can be excluded from this RFC =E2=80=94
everything except the coroutine class and context. Microtasks, of course,
will remain.

As a result, the RFC will be clean and compact, focusing solely on how
coroutines and context work.

Channels, Future, and iterators can be moved to a separate RFC dedicated
specifically to primitives.

Finally, after reviewing the high-level RFCs, we can return to the
implementation =E2=80=94 in other words, top-down. Given that the approxima=
te
structure of the lower level is already clear, discussing abstractions will
remain practical and grounded.

Just to clarify, I=E2=80=99m not planning to end the current discussion the=
se are
just intermediate thoughts.

---

Ed.

>

--0000000000005fa2d3062fcf5eea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello all.</div><div><br></div><div dir=3D"ltr">A few=
 thoughts aloud about the emerging picture.<br><br>### Entry point into the=
 asynchronous context<br>Most likely, it should be implemented as a separat=
e function (I haven&#39;t come up with a good name yet), with a unique name=
 to ensure its behavior does not overlap with other operators. It has a uni=
que property: it waits for the full completion of the event loop and the Sc=
heduler.=C2=A0<br><br>Inside the asynchronous context, `Fiber` is prohibite=
d, and conversely, inside a `Fiber`, the asynchronous context is prohibited=
.<br><br>### The `async` operator<br>The `async` (or <b>spawn</b>?) operato=
r can be used as a shorthand for spawning a coroutine:<br><br>```php<br>fun=
ction my($param) {}<br><br>// Operator used as a function call<br>async my(=
1);<br>or<br>spawn my(1);<br><br>// Operator used as a closure<br>async {<b=
r>=C2=A0 =C2=A0 code<br>};<br><br>// Since it&#39;s a closure, the `use` st=
atement can be used without restrictions<br>async use($var) {<br>=C2=A0 =C2=
=A0 code<br>};<br><br>// Returns a coroutine class instance<br>$x =3D async=
 use($var) {<br>=C2=A0 =C2=A0 code<br>};<br>```<br><br>### The `await` oper=
ator<br>The `await` operator can be added to `async`, allowing explicit sus=
pension of execution to wait for a result:<br><br>```php<br>$x =3D await as=
ync use($var) {<br>=C2=A0 =C2=A0 code<br>};<br>```<br><br>## Context Manipu=
lations<br>I didn&#39;t like functions like `overrideContext`. They allow c=
hanging the context multiple times at any point in a function, which can le=
ad to errors that are difficult to debug. This is a really bad approach. It=
 is much better to declare the context at the time of coroutine invocation.=
 With syntax, it might look like this:<br><br>```php<br>async in $context u=
se() {}<br>async in $context myFun()<br>async in $context-&gt;with(&quot;ke=
y&quot;, value) myFun()<br>or<br>spawn in $context ...<br>```<br><br>## Thr=
ead<br>The syntax <code>spawn in/async in</code> can be used not only in st=
andard cases.=C2=A0=C2=A0</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=
```php</div><div dir=3D"ltr">$coro =3D async in new ThreadContext() use($ch=
annel) {<br>=C2=A0 =C2=A0 while() {}<br>};<br><br>// This expression is als=
o valid<br>$coro =3D async in new $threadPool-&gt;borrowContext() use($chan=
nel) {<br>=C2=A0 =C2=A0 while() {}<br>};<br></div><div dir=3D"ltr">```<br><=
br>It is worth noting that <code>$threadPool</code> itself may be provided =
by an extension and not be a part of PHP.=C2=A0=C2=A0<br><br>## Unrelated C=
oroutines<br>An additional way is needed to create a coroutine that is not =
bound to a parent. <br>It&#39;s worth considering how to make this as clear=
 and convenient as possible.</div><div dir=3D"ltr">Maybe as keyword:</div><=
div dir=3D"ltr"><br></div><div dir=3D"ltr">```php</div><div>async unbound .=
..</div><div dir=3D"ltr">```<br><br>Of course, an `async child` modifier ca=
n be used. This is the inverse implementation, but I think it will not be u=
sed often. Making `unbound` a separate method is not very appealing at the =
moment because a programmer might forget to call it. They could forget the =
word `unbound`, and even more so a whole method.<br><br>## Context Operatio=
ns<br>```php<br>await $context; // Waits for all coroutines in the context<=
br>$context.cancel(); // Cancels everything within the context<br>```<br></=
div><div dir=3D"ltr"><br></div><div>## Flow</div><div dir=3D"ltr"><br></div=
><div dir=3D"ltr">I want to thank all the participants in the discussion.<b=
r>Thanks to your ideas, questions, and examples. A week ago, answering this=
 question would have been impossible.=C2=A0</div><div dir=3D"ltr"><br></div=
><div dir=3D"ltr">If we add exception handling and graceful shutdown, and r=
emove the new syntax by replacing it with an equivalent of 2-3 functions, w=
e will get a fairly cohesive RFC that describes the high-level part without=
 unnecessary details. Channels and even <code>Future</code> can be excluded=
 from this RFC =E2=80=94 everything except the coroutine class and context.=
 Microtasks, of course, will remain.</div><div dir=3D"ltr">
<p>As a result, the RFC will be clean and compact, focusing solely on how c=
oroutines and context work.</p>
<p>Channels, <code>Future</code>, and iterators can be moved to a separate =
RFC dedicated specifically to primitives.</p>
<p>Finally, after reviewing the high-level RFCs, we can return to the imple=
mentation =E2=80=94 in other words, top-down. Given that the approximate st=
ructure of the lower level is already clear, discussing abstractions will r=
emain practical and grounded.</p><p>Just to clarify, I=E2=80=99m not planni=
ng to end the current discussion these are just intermediate thoughts.

</p><p>---</p><p>Ed.</p></div><div class=3D"gmail_quote gmail_quote_contain=
er"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>

--0000000000005fa2d3062fcf5eea--