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 you have a main loop that checks a variable but that variable is set from another part of the processor cycle that has nothing to do with the main loop (it is not fire and forget style it is in real time). Basically you can have a standard `int main()`function that is sync because you can delay in it (yep sleep(0)) and while you block it you have an event that interrupts a function that works on another register which is independent from the main function. More details of this will be probably not interesting so I will stop. If you want to make async PHP with multiple processes you have to check variables semaphored to make it work.
On Sun, Mar 9, 2025 at 8:16 PM Edmond Dantes <edmond...@gmail.com> wrote: > > > > 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 main coroutine or the root coroutine. > > When the index.php script reaches its last instruction, the coroutine > finishes, execution is handed over to the Scheduler, and then everything > proceeds as usual. > > Accordingly, if the Scheduler has more coroutines in the queue, reaching > the last line of index.php does not mean the script terminates. Instead, > it continues executing the queue until... there is nothing left to execute. > > > > > At that point, the relationship to a block syntax perhaps becomes > clearer: > > > > Thanks to the extensive discussion, I realized that the implementation > with startScheduler raises too many questions, and it's better to > sacrifice a bit of backward compatibility for the sake of language elegance. > > After all, Fiber is unlikely to be used by ordinary programmers. > -- Iliya Miroslavov Iliev i.mirosla...@gmail.com
