One person observes 3 persons and he is curious what they are doing because it looks strange. The first person digs a hole. The second person buries the hole. The third person waters the buried hole. He asks them: Why are you doing this? They say: There is a fourth person that plants the seeds but he is sick right now.
On Sat, Mar 8, 2025 at 3:41 PM Daniil Gentili <daniil.gent...@gmail.com> 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. > -- Iliya Miroslavov Iliev i.mirosla...@gmail.com
