# Discussion: "Some thoughts on asynchronous API design in a post-async/await world" **URL:** \ **Category:** Uncategorized\ **Created:** [February 6, 2019, 11:23pm UTC](https://trio.discourse.group/t/discussion-some-thoughts-on-asynchronous-api-design-in-a-post-async-await-world/32 "2019-02-06T23:23:53Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![njs](https://yyz2.discourse-cdn.com/free1/user_avatar/trio.discourse.group/njs/32/11_2.png) [@njs](https://trio.discourse.group/u/njs)\ **Post date:** [February 6, 2019, 11:23pm UTC](https://trio.discourse.group/t/discussion-some-thoughts-on-asynchronous-api-design-in-a-post-async-await-world/32/1 "2019-02-06T23:23:53Z")
You can use this thread to discuss the blog post [Some thoughts on asynchronous API design in a post-async/await world](https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/). It’s long and a bit out-of-date at this point, but this is ultimately where Trio started! ---
**Author:** ![Manganus](https://avatars.discourse-cdn.com/v4/letter/m/7ba0ec/32.png) [@Manganus](https://trio.discourse.group/u/Manganus)\ **Post date:** [February 11, 2019, 12:23pm UTC](https://trio.discourse.group/t/discussion-some-thoughts-on-asynchronous-api-design-in-a-post-async-await-world/32/2 "2019-02-11T12:23:07Z")
Being intimidated by asyncio, I’d been thinking of Curio as a self-study project. Last week I found this blog post, …and trio. Good and short name! Splendid ideas! I don’t know if I’m wrong, but I get the impression that many more than I are intimidated by asyncio and predecessors. Trio would save them, if only they knew. 😉 ---
**Author:** ![sorcio](https://avatars.discourse-cdn.com/v4/letter/s/50afbb/32.png) [@sorcio](https://trio.discourse.group/u/sorcio)\ **Post date:** [February 11, 2019, 1:37pm UTC](https://trio.discourse.group/t/discussion-some-thoughts-on-asynchronous-api-design-in-a-post-async-await-world/32/3 "2019-02-11T13:37:57Z")
@njs I’ve been trying to give a deeper read again at your article and it’s still a fun one. With hindsight, coming from 2019’s Trio, it’s really interesting to see how some ideas have evolved! One thing that I haven’t fully grasped is your definition of _causality_. I have an intuition of it, but when I tried to explain it to others I failed miserably. It’s clear how `f(); g()` “respects causality”, but it’s not easy to describe when concurrent code does or does not. My intuition: if the behavior can be described as a sequence of _predictably_ serial events then it’s “respecting causality”. But the exercise is not trivial (to me), and some complex interactions might be hard to try to explain that way. Lack of a formal method means that I fall back to intuition, which can and will be wrong. Now, this confusion itself is to me the greatest selling point of a language/framework whose building blocks “respect causality” themselves. I would not be able to make something predictable myself as complexity grows beyond trivial, so I rely on something that is structurally more predictable. Kind of like the `goto` vs structured concurrency idea. But it also means that 1) I don’t have a full understanding of the concepts and 2) I won’t be able to explain how great it is to have tools that approach this problem at the root. In order to expand my language and ability to talk about it I hoped to use this notion of “causality”, but is there some (more) formal definition to what is causal and what is not? Is there a better colloquial way to discuss it? ---
**Author:** ![njs](https://yyz2.discourse-cdn.com/free1/user_avatar/trio.discourse.group/njs/32/11_2.png) [@njs](https://trio.discourse.group/u/njs)\ **Post date:** [February 12, 2019, 7:57am UTC](https://trio.discourse.group/t/discussion-some-thoughts-on-asynchronous-api-design-in-a-post-async-await-world/32/4 "2019-02-12T07:57:44Z")
> [@sorcio](#): > > One thing that I haven’t fully grasped is your definition of _causality_ . I have an intuition of it, but when I tried to explain it to others I failed miserably. It’s clear how `f(); g()` “respects causality”, but it’s not easy to describe when concurrent code does or does not. I may have commited the sin of using a fancy word when a plain one would do 🙂. All I mean is: suppose `f` and `g` are two operations with side-effects. If I write `f(); g();`, then `f`’s side-effects should all happen before any of `g`’s side-effects. Or in other words: if I _write_ `f` before `g`, then `f` should _happen_ before `g` :-). It’s probably easiest to explain with examples: - `f` is “make an edit to a document”, `g` is “share the document with other people”. Whoops, maybe you just sent the old version of your document, with the embarrassing mistake you thought you already corrected! - `f` is “send this data”, `g` is “terminate the program”. Whoops, maybe the data is never sent! In fact this works with practically anything in the `f` slot, which is why it’s so difficult to properly shut down a program using twisted or asyncio. - `f` is “write the new version to disk”, `g` is “delete the old version”. Doing it in this order guarantees you won’t lose data if the system crashes, right? Well, maybe not, if your system reorders it so `g` happens first. (Bonus: unless your test suite simulates random power outages, the only way you will discover this bug is because it destroyed production data.) - `f` is “send data to the remote peer”, `g` is “generate more data to send”. If the peer stops reading, you want to stop generating new data. Twisted/asyncio protocols don’t enforce this, which is why innocent-looking Twisted/asyncio programs are so prone to memory DoS. ---
**Author:** ![jxsd](https://avatars.discourse-cdn.com/v4/letter/j/7bcc69/32.png) [@jxsd](https://trio.discourse.group/u/jxsd)\ **Post date:** [March 20, 2025, 7:13pm UTC](https://trio.discourse.group/t/discussion-some-thoughts-on-asynchronous-api-design-in-a-post-async-await-world/32/5 "2025-03-20T19:13:57Z")
Still an interesting article in 2025. One question: In this section: > **[Some thoughts on asynchronous API design in a post-async/await world — njs blog](https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/#cleanup-in-generators-and-async-generators)** I think there are a few typos in the async generator code. The ` __aclose__ ` method definition in `aclosing` class should be changed to: ```auto async def __aexit__ (..): ``` Right?