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
