On Sun, Mar 16, 2025, at 10:24, Edmond Dantes wrote:
> Good day, everyone. I hope you're doing well.
>
> https://wiki.php.net/rfc/true_async
>
> Here is a new version of the RFC dedicated to asynchrony.
>
> Key differences from the previous version:
>
> * The RFC is not based on Fiber; it introduces a separate class representation for the
> asynchronous context.
> * All low-level elements, including the Scheduler and Reactor, have been removed from the RFC.
> * The RFC does not include Future, Channel, or any other primitives, except those directly
> related to the implementation of structured concurrency.
>
> The new RFC proposes more significant changes than the previous one; however, all of them are
> feasible for implementation.
>
> I have also added PHP code examples to illustrate how it could look within the API of this RFC.
>
> I would like to make a few comments right away. In the end, the Kotlin model lost, and the RFC
> includes an analysis of why this happened. The model that won is based on the Actor approach,
> although, in reality, there are no Actors, nor is there an assumption of implementing encapsulated
> processes.
>
> On an emotional level, the chosen model prevailed because it forces developers to constantly
> think about how long coroutines will run and what they should be synchronized with. This somewhat
> reminded me of Rust’s approach to lifetime management.
>
> Another advantage I liked is that there is no need for complex syntax like in Kotlin, nor do we
> have to create separate entities like Supervisors and so on. Everything is achieved through a simple
> API that is quite intuitive.
>
> Of course, there are also downsides — how could there not be? But considering that PHP is a
> language for web server applications, these trade-offs are acceptable.
>
> I would like to once again thank everyone who participated in the previous discussion. It was
> great!
Hey Edmond,
Here are my notes:
> The *Scheduler* and *Reactor* components should be described in a separate *RFC*, which should
> focus on the low-level implementation in *C* and define *API* contracts for PHP extensions.
Generally, RFCs are for changes in the language itself, not for API contracts in C. That can
generally be handled in PRs, if I understand correctly.
> The suspend function has no parameters and does not return any values, unlike the
> yield operator.
If it can throw, then it does return values? I can foresee people abusing this for flow control and
passing out (serialized) values of suspended coroutines. Especially if it is broadcast to all other
coroutines awaiting it. It is probably simpler to simply allow passing a value out via suspend.
> The suspend function can be used in any function and in any place including from
> the main execution flow:
Does this mean it is an expression? So you can basically do:
return suspend();
$x = [suspend(), suspend(), suspend()];
foreach ($x as $_) {}
or other weird shenanigans? I think it would be better as a statement.
> The await function/operator is used to wait for the completion of another
> coroutine:
What happens if it throws? Why does it return NULL; why not void or the result of the
awaited spawn?
> The register_shutdown_function handler operates in synchronous mode, after
> asynchronous handlers have already been destroyed. Therefore, the
> register_shutdown_function code should not use the concurrency API. The
> suspend() function will have no effect, and the spawn operation will not
> be executed at all.
Wouldn't it be better to throw an exception instead of silently failing?
From this section, I really don't like the dual-syntax of spawn, it is
function-like, except not. In other words, this won't behave like you would expect it to:
spawn ($is_callable ? $callable : $default_callable)($value);
I'm not sure what will actually happen here.
---
When comparing the three different models, it would be ideal to keep to the same example for all
three and describe how their execution differs between the example. Having to parse through the
examples of each description is a pain.
> Child coroutines inherit the parent's Scope:
Hmm. Do you mean this literally? So if I call a random function via spawn, it will have access to my
current scope?
function foo() {
$x = 'bar';
}
$x = 'baz';
$scope->spawn(foo(...));
echo $x; // baz or bar??
That seems like a massive footgun. I think you mean to say that it would behave like normal. If you
spawn a function, it behaves like a function, if you spawn a closure, it closes over variables just
like normal. Though I think it is worth defining "when" it closes over the variables --
when it executes the closure, or when it hits the spawn.
Does "spawn" not provide a \Scope?
---
I still don't understand the need for a special context thing. One of the most subtle footguns
with go contexts is to propagate the context when it shouldn't be propagated. For example, if
you are sending a value to a queue, you probably don't want to send the request context. If you
did and the request was cancelled (or even just completed!), it would also cancel putting the value
on the queue -- which is almost certainly what you do *not* want. Since the context is handled for
you, you also have to worry about a context disappearing while you are using it, from the looks of
things.
This can be easily built in userland, so I'm not sure why we are defining it as part of the
language.
> To ensure data encapsulation between different components, *Coroutine Scope Slots* provide the
> ability to associate data using *key objects*. An object instance is unique across the entire
> application, so code that does not have access to the object cannot read the data associated with
> it.
heh, reminds me of records.
---
I know I have been critical in this email, but I actually like it; for the most part. I think there
are still some rough edges to sand down and polish, but it is on the right track!
— Rob