Re: PHP True Async RFC

On Sat, Mar 8, 2025, at 14:38, Daniil Gentili wrote: > > > The async block as I'm picturing it has nothing to do with function colouring, > > it's about the outermost function in an async stack being able to say "make sure the > > scheduler is started" and "block here until all child fibers are either concluded, > > detached, or cancelled". > > There's no need for such a construct, as the awaitAll function does precisely what you > describe, without the need to introduce the concept of a child fiber and the excessive limitation of > an async block that severely limits concurrency. > > There is absolutely nothing wrong with the concept of a fiber without a parent, or a fiber that > throws an exception (or a cancellation exception) out of the event loop. > > A panic in a golang fiber surfaces out of the event loop (unless it is catched with a recover), > just like an uncatched exception in a fiber surfaces out of the event loop: it makes no sense to > severely limit concurrency with an async block just to handle the edge case of an uncaught exception > (which can be handled anyway with an event loop exception handler). > > In general, I really don't like the concept of an async block the way it is presented > here, because it implies that concurrency is something bad that must be limited and controlled, or > else bad stuff will happen, when in reality, a fiber throwing an exception (without anyone > await()ing on the fiber handle, thus throwing out of the event loop) is not the end of the world, > and can be handled by other means, without limiting concurrency. > > Regards, > Daniil Gentili. As far as I can tell, the entire reason we are talking about this is because adding the event loop changes the behavior of existing code. So we cannot "just turn it on". I haven't seen an explanation of why this is the case, but that's how we got to this point. We need some way to "opt in" to turning on the event loop. — Rob