Re: [PHP-DEV] Re: PHP True Async RFC Stage 3

2025-05-29 Thread Edmond Dantes
Hello, Carlos! Thank you for your support. I feel like I should add a bit of jam to this story and share some news. When I set the two-week limit for the vote, Roman Pronskiy reached out to me almost immediately and offered direct contact with PHP CORE. I received maximum support and valuable adv

[PHP-DEV] Re: PHP True Async RFC Stage 3

2025-05-28 Thread carlos_silvaaaaa
Hello everyone. I've been thinking about core developers these days, and I'm happy to see the PHP foundation growing, and more and more new developers arriving, eager to push PHP forward. But at the same time, I have the feeling that some want to own it, are jealous, or are simply arrogant. T

[PHP-DEV] Re: PHP True Async RFC Stage 3

2025-05-14 Thread Edmond Dantes
Hello, everyone. While the code is being developed and changes for the RFC are in progress, I’d like to share a real-world situation. This is one of those cases that once again proves why software design cannot happen without writing real code — why architecture is impossible without practice. `

[PHP-DEV] Re: PHP True Async RFC - Stage 2

2025-04-04 Thread Edmond Dantes
Good day, everyone. Just a ping email — I haven’t disappeared, development is ongoing. Since the task has a high level of interdependency, I have to cautiously try different combinations. The second-to-last version, in trying to satisfy all requirements, turned out too complex to be taken serious

[PHP-DEV] Re: PHP True Async RFC - Stage 2

2025-03-26 Thread Edmond Dantes
Hello everyone, It's a nice Sunday evening, and I'd like to share some updates and thoughts from this week — kind of like a digest :) 1. Big thanks to Rowan Tommins for the syntax suggestions, ideas, and feedback. I decided to try using the `spawn block` syntax, and in practice, it turned out to

[PHP-DEV] Re: PHP True Async RFC - Stage 2

2025-03-21 Thread Edmond Dantes
Good day, everyone. As I write more code examples, I'm starting to get annoyed by the verbosity of the `spawn in $scope` construct—especially in situations where all spawns need to happen within the same context. At the same time, in 80% of cases, it turns out that explicitly defining `$scope` is

Re: [PHP-DEV] Re: PHP True Async RFC - Stage 2

2025-03-20 Thread Edmond Dantes
> > await $some limit 5s; > Yes, limit is also a good keyword. And some else examples with "until": **CancellationExp**: - A variable of the `Awaitable` interface ```php $cancellation = new Future(); $result = await $coroutine until $cancellation; ``` - A function that returns an Awai

Re: [PHP-DEV] Re: PHP True Async RFC - Stage 2

2025-03-20 Thread Iliya Miroslavov Iliev
```php await $some with 5s; ``` Maybe ```php await $some limit 5s; ``` On Thu, Mar 20, 2025 at 9:33 AM Edmond Dantes wrote: > Hello everyone, > I’d like to ask for your help regarding the syntax. > > **Goal:** I want to get rid of the `BoundedScope` object while still > providing a convenient

[PHP-DEV] Re: PHP True Async RFC - Stage 2

2025-03-20 Thread Edmond Dantes
Hello everyone, I’d like to ask for your help regarding the syntax. **Goal:** I want to get rid of the `BoundedScope` object while still providing a convenient built-in tool for controlling wait time. To achieve this, we could extend the `await` expression so that it allows explicitly specifying

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-15 Thread Rowan Tommins [IMSoP]
On 10 March 2025 03:55:21 GMT, Larry Garfield wrote: >Support for nested blocks is absolutely mandatory, whatever else we do. If >you cannot nest one async block (scheduler instance, coroutine, whatever it >is) inside another, then basically no code can do anything async except the >top lev

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-10 Thread Edmond Dantes
>function par_map(iterable $it, callable $c) { > $result = []; > async { >foreach ($it as $val) { > $result[] = $c($val); >} > } >return $result; >} If the assumption is that each call can be asynchronous and all elements need to be processed, the only proper tool is a concurrent i

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-09 Thread Larry Garfield
On Sun, Mar 9, 2025, at 8:17 AM, Rowan Tommins [IMSoP] wrote: > That leaves the question of whether it would ever make sense to nest > those blocks (indirectly, e.g. something() itself contains an async{} > block, or calls something else which does). > > I guess in our analogy, nested blocks cou

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-09 Thread Rob Landers
On Sun, Mar 9, 2025, at 14:17, Rowan Tommins [IMSoP] wrote: > On 08/03/2025 20:22, Edmond Dantes wrote: > > > > For coroutines to work, a Scheduler must be started. There can be only > > one Scheduler per OS thread. That means creating a new async task does > > not create a new Scheduler. > > > >

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-09 Thread Edmond Dantes
> Edmond, > > If you want to make async PHP with multiple processes you have to check > variables semaphored to make it work. > > Hello, Iliya. Thank you for your feedback. I'm not sure if I fully understood the entire context. But. At the moment, I have no intention of adding multitasking

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-09 Thread Iliya Miroslavov Iliev
Edmond, The language barrier is bigger (because of me, I cannot properly explain it) so I will keep it simple. Having "await" makes it sync, not async. In hardware we use interrupts but we have to do it grandma style... The main loop checks from variables set on the interrupts which is async. So yo

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-09 Thread Edmond Dantes
> > I think the same thing applies to scheduling coroutines: we want the Scheduler to take over the "null fiber", > Yes, you have quite accurately described a possible implementation. When a programmer loads the initial index.php, its code is already running inside a coroutine. We can call it the

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-09 Thread Rowan Tommins [IMSoP]
On 08/03/2025 20:22, Edmond Dantes wrote: For coroutines to work, a Scheduler must be started. There can be only one Scheduler per OS thread. That means creating a new async task does not create a new Scheduler. Apparently, async {} in the examples above is the entry point for the Scheduler

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-08 Thread Edmond Dantes
> > This is incorrect. "Create an async bounded context playpen" (what I called "async" in my example) > and "start a fiber/thread/task" (what I called "spawn") are two *separate* operations, and > must remain so. > > So, you use *async* to denote the context and *spawn* to create a coroutine. Re

Re: [PHP-DEV] Re: PHP True Async RFC

2025-03-08 Thread Larry Garfield
On Sat, Mar 8, 2025, at 1:05 AM, Edmond Dantes wrote: > 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

[PHP-DEV] Re: PHP True Async RFC

2025-03-07 Thread Edmond Dantes
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