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 <[email protected]>
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
[email protected]