[HN Gopher] Structured Concurrency Definition (2019)
       ___________________________________________________________________
        
       Structured Concurrency Definition (2019)
        
       Author : ingve
       Score  : 27 points
       Date   : 2023-02-05 12:28 UTC (10 hours ago)
        
 (HTM) web link (gavinhoward.com)
 (TXT) w3m dump (gavinhoward.com)
        
       | mananaysiempre wrote:
       | I like structured concurrency (in its Trio embodiment). I'd love
       | to go all in on structured concurrency... except I see no way to
       | marry it (or async/await-style syntax) to promise pipelining,
       | which seems to be the only sane avenue to avoiding the roundtrip
       | tax on fine-grained remote APIs[1]. Is anyone aware of any
       | attempts in this area?
       | 
       | [1] https://capnproto.org/rpc.html
        
         | gavinhoward wrote:
         | I could implement something like this.
         | 
         | First, instead of calling a function, just add that function to
         | a list of functions. Then when you're done, spawn a thread and
         | pass it the needed data and the list of functions. The thread
         | will work its way through the chain.
         | 
         | This technique is possible because "closures are just a poor
         | man's object." (I think I saw that on the c2 wiki.)
        
           | alwaysbeconsing wrote:
           | > "closures are just a poor man's object."
           | 
           | Yes; the inverse is also true :) The "koan" is on c2 here:
           | http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent (with a
           | link to its original source).
        
             | mananaysiempre wrote:
             | (Musings not that relevant to asynchronous ocap messaging,
             | where the problems don't really depend on whether you're
             | passing around objects or closures.)
             | 
             | One thing I don't think I've seen mentioned on those pages
             | is the distinction between a "closed" object you can only
             | send messages to and an "open" one you can inherit from /
             | delegate to / mix in / COM-aggregate: the former is indeed
             | a closure, that is some code and an environment, that you
             | feed the message selector and some arguments; the latter is
             | also some code and an environment, but you feed it _the
             | resend target_ , the message selector, and some arguments.
             | So depending on what exactly you're calling an object, an
             | object is a closure... in one of two non-equivalent ways.
             | Maybe not really a closure then?
             | 
             | See also for not-quite-identical points of view: Piumarta's
             | note on prototypes in his COLA system[1]; Chisnall's
             | description of the (IIUC now-dead) new Objective-C runtime
             | for Etoile[2].
             | 
             | [1] https://www.piumarta.com/pepsi/prototypes.html
             | 
             | [2] https://www.jot.fm/issues/issue_2009_01/article4.pdf
        
             | gavinhoward wrote:
             | Yes, that's the one!
        
       | gavinhoward wrote:
       | 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...
        
         | rerdavies wrote:
         | To the author: The disclaimer is needlessly @ssh0lish.
        
           | gavinhoward wrote:
           | On the post?
           | 
           | Not really. I've had people go after me for such things.
        
             | rerdavies wrote:
             | Now you have people like me after you for the disclaimer.
             | There is another solution.
        
               | gavinhoward wrote:
               | Self-censoring isn't an option, but if you have another,
               | I'd be happy to listen.
        
         | rerdavies wrote:
         | 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.
        
         | mananaysiempre wrote:
         | 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 wrote:
           | 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 wrote:
         | 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 wrote:
           | 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 wrote:
             | https://elizarov.medium.com/structured-
             | concurrency-722d765aa...
             | https://elizarov.medium.com/coroutine-context-and-
             | scope-c8b2...
             | https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-
             | corout...
        
               | gavinhoward wrote:
               | Thank you!
               | 
               | To answer the GGP, this looks like true structured
               | concurrency to me. Chalk one up for Kotlin!
        
         | manmal wrote:
         | Do you think that what Swift implemented can be called
         | structured concurrency by your definition?
        
           | gavinhoward wrote:
           | Yes. Swift beat me to it.
        
       | kzuberi wrote:
       | A useful introduction to the ideas is in Nathaniel's PyCon 2018
       | talk on trio [1], where he live-codes a solution to a
       | concurrency-spaghetti problem.
       | 
       | [1] https://www.youtube.com/watch?v=oLkfnc_UMcE
        
       | convolvatron wrote:
       | is similar to nested dag? not exactly because it can contain
       | loops, but children never outlive their parent?
        
         | gavinhoward wrote:
         | Basically, though I've also extended the idea since.
        
       ___________________________________________________________________
       (page generated 2023-02-05 23:02 UTC)