On 8 March 2025 13:38:30 GMT, 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.
No, it's not quite that either. The scenario I have in mind is a web / network
server spawning a fiber for each request, and wanting to know when everything
related to that request is finished, so that it can manage resources.
If we think of memory management as an analogy, awaitAll would be equivalent to
keeping track of all your memory pointers, and making sure to pass them all to
free before the end of the request. The construct we're discussing is like a
garbage collection checkpoint, that ensures all memory allocated within that
request has been freed, even if it wasn't tracked anywhere.
Written in ugly functions rather than concise and fail-safe syntax, it's
something like:
$managedScope = new ManagedScope;
$previousScope = set_managed_scope( $managedScope );
spawn handle_request(); // inside here any number of fibers might be spawned
$managedScope->awaitAllChildFibers(); // we don't have the list of fibers here,
so we can't use a plain awaitAll
set_managed_scope( $previousScope );
unset($managedScope);
It's certainly worth discussing whether this should be mandatory, default with
an easy opt-out, or an equal-footing alternative to go-style unmanaged
coroutines. But the idea of automatically cleaning up resources at the end of a
task (e.g. an incoming request) is not new, and nor is arranging tasks in a
tree structure.
I would also note that the concept of parent and child fibers is also useful
for other proposed features, such as cascading cancellations, and having
environment-variable style inherited context data. None of those is
*essential*, but unless there are major *implementation* concerns, they seem
like useful features to offer the user.
Rowan Tommins
[IMSoP]
