3 ms·

Author here. It's interesting to see this posted after three years. In fact, there should be "(2019)" in the Hacker News title. After looking at the definiti

Author here. It's interesting to see this posted after three years. In fact, there should be "(2019)" in the Hacker News title. After looking at the definition, I think it holds up well. I would probably tweak it, but I was three years less experienced back then. It's weird to think that I posted that just two months before lockdown. It seems like I posted it long before that...

mananaysiempre 4y ago
Small quibble with the article: It refers to Trio nurseries as “scopes”. I thought about them like that for a while, but don’t think that’s not exactly the right view now. As a subroutine, you can’t (usually) reach up into your parent static or dynamic scopes and cause new objects to be created there and outlive your own dynamic extent. (Tcl exempted.) Because nurseries are first-class objects, though, you’re free to create a root nursery at startup and stick it in a global variable, after which everyone is free to create as many Go-style unaccountable threads as they want to. It’s just that you don’t have to. Yet passing worker threads their originating nursery so that they can spawn more peer workers is a moderately useful pattern. TL;DR: Firsr-class nurseries are not quite scopes because they don’t enforce strict lifetime nesting between a spawned thread and the thread that caused it to be spawned.
- gavinhoward 4y ago
  One of the tweaks I would use is to use the word "lifetimes" instead of scopes. I think this would since the problem you see because each object, even a nursery, has a lifetime, and threads are tied to those lifetimes.
MarkMarine 4y ago
More than just I read your article about C and memory safety today and went clicking around in the archive. Good work. When I read the Go statement considered harmful post, I felt the same thing. This just makes sense, everything should be like this. A number of these ideas have been designed into Kotlin’s concurrency library, what are your thoughts about it?
- gavinhoward 4y ago
  Thank you! I haven't seen Kotlin's library, so I can't comment. Do you have a link? I wasn't able to pull up anything good with a search.
  - garrybelka 4y ago
    https://elizarov.medium.com/structured-concurrency-722d765aa952 https://elizarov.medium.com/structured-concurrency-722d765aa... https://elizarov.medium.com/coroutine-context-and-scope-c8b255d59055 https://elizarov.medium.com/coroutine-context-and-scope-c8b2... https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/launch.html https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout...
    - gavinhoward 4y ago
      Thank you! To answer the GGP, this looks like true structured concurrency to me. Chalk one up for Kotlin!
manmal 4y ago
Do you think that what Swift implemented can be called structured concurrency by your definition?
- gavinhoward 4y ago
  Yes. Swift beat me to it.
rerdavies 4y ago
To the author: The disclaimer is needlessly @ssh0lish.
- gavinhoward 4y ago
  On the post? Not really. I've had people go after me for such things.
  - rerdavies 4y ago
    Now you have people like me after you for the disclaimer. There is another solution.
    - gavinhoward 4y ago
      Self-censoring isn't an option, but if you have another, I'd be happy to listen.
    - strawpeople 4y ago
      What’s wrong with his disclaimer?
rerdavies 4y ago
Kinda like std::jthread. Definitely a good thing. But does that really justify the label "structured concurrency"? I was rather hoping to see something more, especially since languages like Rust, Go, JavaScript (and even Python) go much further.
- jerf 4y ago
  Go goes "beyond" structured concurrency in the same sense that BASIC goes "beyond" structured programming because it has a "goto" statement. That is, it goes "beyond" it by being incapable of guaranteeing it at all. The entire point of structured concurrency or structured programming is to build limitations into the system, then build other guarantees on those limitations. If you don't have the limitations, you don't have the things you can build on it. Systems lacking those limitations do not "go beyond" the limitations, they lack the ability to build the guarantees. I have been influenced in my Go programming by this essay. A lot of my concurrency is actually "structured concurrency" if you look at it. But you have to look at it to see, because there is no way for me to guarantee it structurally. No matter how much I use the ideas, no matter how much I were to write it into an API, I can never prevent anything from blasting a "go" statement whereever they want, whenever they want, and violating the limitations, and thus breaking the guarantees. This is not the end of the world some programmers treat it as; no language can do everything and enforce everything and be perfect without the programmer having to bring some discipline to the party. But neither is it no big deal at all and something you can just wave away with a vague statement about how some programmers just need to be better programmers or something. These things matter.

mananaysiempre 4y ago

Small quibble with the article: It refers to Trio nurseries as “scopes”. I thought about them like that for a while, but don’t think that’s not exactly the right view now. As a subroutine, you can’t (usually) reach up into your parent static or dynamic scopes and cause new objects to be created there and outlive your own dynamic extent. (Tcl exempted.) Because nurseries are first-class objects, though, you’re free to create a root nursery at startup and stick it in a global variable, after which everyone is free to create as many Go-style unaccountable threads as they want to. It’s just that you don’t have to. Yet passing worker threads their originating nursery so that they can spawn more peer workers is a moderately useful pattern. TL;DR: Firsr-class nurseries are not quite scopes because they don’t enforce strict lifetime nesting between a spawned thread and the thread that caused it to be spawned.

gavinhoward 4y ago
One of the tweaks I would use is to use the word "lifetimes" instead of scopes. I think this would since the problem you see because each object, even a nursery, has a lifetime, and threads are tied to those lifetimes.

MarkMarine 4y ago

More than just I read your article about C and memory safety today and went clicking around in the archive. Good work. When I read the Go statement considered harmful post, I felt the same thing. This just makes sense, everything should be like this. A number of these ideas have been designed into Kotlin’s concurrency library, what are your thoughts about it?

gavinhoward 4y ago
Thank you! I haven't seen Kotlin's library, so I can't comment. Do you have a link? I wasn't able to pull up anything good with a search.
- garrybelka 4y ago
  https://elizarov.medium.com/structured-concurrency-722d765aa952 https://elizarov.medium.com/structured-concurrency-722d765aa... https://elizarov.medium.com/coroutine-context-and-scope-c8b255d59055 https://elizarov.medium.com/coroutine-context-and-scope-c8b2... https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/launch.html https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout...
  - gavinhoward 4y ago
    Thank you! To answer the GGP, this looks like true structured concurrency to me. Chalk one up for Kotlin!

manmal 4y ago

Do you think that what Swift implemented can be called structured concurrency by your definition?

gavinhoward 4y ago
Yes. Swift beat me to it.

rerdavies 4y ago

To the author: The disclaimer is needlessly @ssh0lish.

gavinhoward 4y ago
On the post? Not really. I've had people go after me for such things.
- rerdavies 4y ago
  Now you have people like me after you for the disclaimer. There is another solution.
  - gavinhoward 4y ago
    Self-censoring isn't an option, but if you have another, I'd be happy to listen.
  - strawpeople 4y ago
    What’s wrong with his disclaimer?

rerdavies 4y ago

Kinda like std::jthread. Definitely a good thing. But does that really justify the label "structured concurrency"? I was rather hoping to see something more, especially since languages like Rust, Go, JavaScript (and even Python) go much further.

jerf 4y ago
Go goes "beyond" structured concurrency in the same sense that BASIC goes "beyond" structured programming because it has a "goto" statement. That is, it goes "beyond" it by being incapable of guaranteeing it at all. The entire point of structured concurrency or structured programming is to build limitations into the system, then build other guarantees on those limitations. If you don't have the limitations, you don't have the things you can build on it. Systems lacking those limitations do not "go beyond" the limitations, they lack the ability to build the guarantees. I have been influenced in my Go programming by this essay. A lot of my concurrency is actually "structured concurrency" if you look at it. But you have to look at it to see, because there is no way for me to guarantee it structurally. No matter how much I use the ideas, no matter how much I were to write it into an API, I can never prevent anything from blasting a "go" statement whereever they want, whenever they want, and violating the limitations, and thus breaking the guarantees. This is not the end of the world some programmers treat it as; no language can do everything and enforce everything and be perfect without the programmer having to bring some discipline to the party. But neither is it no big deal at all and something you can just wave away with a vague statement about how some programmers just need to be better programmers or something. These things matter.