Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126784
Message-ID: <abe64aaf-2894-45b7-b603-5e6e0750f8f7@scriptfusion.com>
Date: Sun, 16 Mar 2025 13:34:34 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC - Stage 2
To: internals@lists.php.net
References: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAMW7n8DQqUhnb+U+WcA7bJ-APRDTtzuJC4m8s-q_2LH7bEuH+A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: bilge@scriptfusion.com (Bilge)

On 16/03/2025 09: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!

Looks tremendous, at a glance. Thanks for your work on this.

Just one quick question for now; why is `suspend()` a function and not a 
statement?

Cheers,
Bilge