[Async-sig] New blog post: Notes on structured concurrency, or: Go statement considered harmful

Dima Tisnek dimaqq at gmail.com
Thu Apr 26 22:55:21 EDT 2018

My 2c after careful reading:

restarting tasks automatically (custom nursery example) is quite questionable:
* it's unexpected
* it's not generally safe (argument reuse, side effects)
* user's coroutine can be decorated to achieve same effect

I'd say just remove this, it's not relevant to your thesis.

It's very nice to have the escape hatch of posting tasks to "someone
else's" nursery.
I feel there are more caveats to posting a task to parent's or global
nursery though.
Consider that local tasks typically await on other local tasks.
What happens when N1-task1 waits on N2-task2 and N2-task9 encounters an error?
My guess is N2-task2 is cancelled, which by default cancels N1-task1 too, right?
That kinda break the abstraction, doesn't it?

If the escape hatch is available, how about allowing tasks to be moved
between nurseries?
Is dependency inversion allowed?
(as in given parent N1 and child N1.N2, can N1.N2.t2 await on N1.t1 ?)
If that's the case, I guess it's not a "tree of tasks", as in the
graph is arbitrary, not DAG.

I've seen [proprietary] strict DAG task frameworks.
while they are useful to e.g. perform sub-requests in parallel,
they are not general enough to be useful at large.
Thus I'm assuming trio does not enforce DAG...

Finally, slob programmers like me occasionally want fire-and-forget
tasks, aka daemonic threads.
Some are long-lived, e.g. "battery status poller", others short-lived,
e.g. "tail part of low-latency logging".
Obv., a careful programmer would keep track of those, but we want
things simple :)
Perhaps in line with batteries included principle, trio could include
a standard way to accomplish that?

Thanks again for the great post!
I think you could publish an article on this, it would be good to have
wider discussion, academic, ES6, etc.

On 25 April 2018 at 17:24, Nathaniel Smith <njs at pobox.com> wrote:
> Hi all,
> I just posted another essay on concurrent API design:
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
> This is the one that finally gets at the core reasons why Trio exists;
> I've been trying to figure out how to write it for at least a year
> now. I hope you like it.
> (Guido: this is the one you should read :-). Or if it's too much, you
> can jump to the conclusion [1], and I'm happy to come find you
> somewhere with a whiteboard, if that'd be helpful!)
> -n
> [1] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#conclusion
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Async-sig mailing list
> Async-sig at python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/

More information about the Async-sig mailing list