From my understanding of the article, you would cause an exception within one of those “nurseries” and that would cause it to shutdown itself and all subtasks, bubbling up the exeception until it gets caught somewhere. So I guess in a Zig context an unhandled error would cause the nursery to shutdown and the subtasks.
It seems to me like this could be a nice way to structure things, if it is well integrated with the language. In terms of lisp lingo I think the idea could be described as context objects that constrain the dynamic extend of asynchronous sub tasks to a lexical scope. It reminds me a bit of rackets custodians and also what the article mentions, erlangs nested supervisors (although I think they might be quite different on a detailed level).
I was wondering a bit, whether the tree structure would have any bad restrictions on the allowed possible programs, but considering that you can add new tasks by essentially passing a reference to the nursery and then reading from a queue creating a subtask for items if wanted, it seems you can do pretty dynamic data dependent things within it.
To me it seems like it could be a useful way to organize high level control, supervising and possibly restart behavior, or maybe even redundancy. In that sense it seems similar to how erlang seems to work (I mostly have some anecdotal / theoretical knowledge of erlang). And also could be useful if your problem happens to be processed in a tree structure.
I wonder whether certain graph problems would cause this organization pattern to become useless / (not helpful in the context of the algorithm / have an impedance mismatch) until the graph part is solved (by using a different set of mechanisms, to coordinate and syncronize on progress).
It seems that graph like things, would either have to use other ways to syncronize or map things in weird ways to add an indirection, or they would be expressed in terms of one specific way to walk the graph (with caching which node has already been visited) which would basically flatten the graph into a tree.
some more thoughts
- I think having some level of nested restart-ability could be interesting in many programs
- I think certain sub problems may still benefit from other ways to synchronize internally, until the sub-problem is solved
- this reminds me a bit of Enter The Arena - Ryan Fleury, that uses tree like life times for nested arenas
- if you could use this to express (memory, cpu, file-system, network, etc.) usage constraints it would be especially nice
- this seems somewhat similar to the plans of making io operations require an interface similar to
allocator - with the added detail that, this nursery interface allows you to group a bunch of sub tasks in a standardized way
- this could potentially allow you to implement specialized nurseries that could do different things, instead of everyone manually having to join/shutdown/inspect/resource-limit/etc. sub tasks in ad-hoc ways in their programs
- I imagine a standardized way to limit resource usage / access to things, would be good for webservers and similar programs that potentially communicate with a lot of different clients, or libraries that are intended to be used in these situations
- if you can start all the things through the io interface, but there isn’t a way to potentially stop them, that would seem incomplete, making the case for having something, that also is able to shutdown things
- that said, I also could see the argument for saying that Zig operates on a lower level, where you have to handle these things yourself and if you want higher level, that is an application level protocol that needs to be followed