Well they lost me at the callbacks... if go statements are harmful and callbacks are not then I rather prefer the harmful way.
Notes on structured concurrency, or: Go statement considered harmful
61–70 of 234 posts
Re: Notes on structured concurrency, or: Go statement considered harmful
#62Earlier quoted context omitted.
> I only see his nursery as being useful when you really want your async tasks to complete before the function in which they were dispatched returns. That's far from covering every use case of concurrency! His section "There is an escape" answers this criticism: "The nursery object also gives us an escape hatch. What if you really do need to write a function that spawns a background task, where the background task ou…
Then what is the difference between the nursery escape and joining a thread or extracting the value of a promise? Both of these will bubble any error back into the dispatch thread. Seems like we're just layering indirections (I wouldn't call that an abstraction) for little added value over the existing constructs.
The difference is that you can look at function, see it takes no nurseries as parameters, and know it does not spawn any background tasks. And if it does take nurseries, then you know it's likely that it does.
Re: Notes on structured concurrency, or: Go statement considered harmful
#63The author appears to have reinvented Communicating Sequential Processes (CSP). http://www.usingcsp.com/cspbook.pdf The (simplified, and as I understand it) gist of concurrency in CSP is that the program is expressed as a series of parallel (PAR) and sequential (SEQ) operations. Everything in a PAR block will run in parallel and all their outputs will be collected and fed as the input to the next SEQ. Everything in a…
This is realised in a real language as occam. I've never understood why so few languages have a par construct, it's much more natural than asynchronous launching.
Re: Notes on structured concurrency, or: Go statement considered harmful
#64Hmm.. Looks like the author is reinventing fork-join style parallelism...
Re: Notes on structured concurrency, or: Go statement considered harmful
#65Earlier quoted context omitted.
Then what is the difference between the nursery escape and joining a thread or extracting the value of a promise? Both of these will bubble any error back into the dispatch thread. Seems like we're just layering indirections (I wouldn't call that an abstraction) for little added value over the existing constructs.
The difference is that you can look at function, see it takes no nurseries as parameters, and know it does not spawn any background tasks. And if it does take nurseries, then you know it's likely that it does.
Whats the difference between taking a nursery and returning a promise? Both put the context in the signature, but the later is actually composable.
Re: Notes on structured concurrency, or: Go statement considered harmful
#66The author appears to have reinvented Communicating Sequential Processes (CSP). http://www.usingcsp.com/cspbook.pdf The (simplified, and as I understand it) gist of concurrency in CSP is that the program is expressed as a series of parallel (PAR) and sequential (SEQ) operations. Everything in a PAR block will run in parallel and all their outputs will be collected and fed as the input to the next SEQ. Everything in a…
The neat thing is that PAR and SEQ do not compose mere operations; they compose other CSP processes. This gives CSP a very regular, self-similar structure.
(The "basic" processes are just the send/receive of a value over a channel. By the way, Go channels are a direct lift from CSP!)
Re: Notes on structured concurrency, or: Go statement considered harmful
#67Earlier quoted context omitted.
A process has much higher overhead (both in time and space), more complex communications and is not always possible in the first place. It also adds complexity to the build pipeline. These quickly adds up to being not worth it over a task or thread. You wouldn't spawn a process for the rendering/input/physics/network/job/loader threads of a game engine for one. You can't spawn processes from a web app either. Threads…
> A process has much higher overhead (both in time and space), more complex communications and is not always possible in the first place. This can change if OSes start optimizing for the proposed convention. > It also adds complexity to the build pipeline. At least in C/C++ it doesn't. But again, this is also easily solvable if we want to. > You wouldn't spawn a process for the rendering/input/physics/network/job/loa…
> This can change if OSes start optimizing for the proposed convention.
What conventions? Its not realistic to assume the world will change to fit your views of software :p
> At least in C/C++ it doesn't.
Sure does; it adds more build targets, gets you to maintain shared code across executables, and plan deployment for multiple executables instead of one. Thats all before even coding the support for that.
> Why not?
Because these depend on shared memory and ownership transfer for performance; you'll drastically drop performance just for the sake of isolation.
> No reason for it to stay that way.
I will literally stop using the web if pages can spawn processes :)
> I won't pretend to know all those words :P
Hehe, basically immutability makes it so nobody can mutate data, thus making it safe to be shared across threads. Uniqueness will transfer ownership such that only one thread has references to a mutable piece of memory at any time. Deterministic parallelism means its impossible to have race conditions or deadlocks.
> I just think the article's proposal has some merit and we should consider it.
Agreed, I'm still having a hard time seeing it however :p
Re: Notes on structured concurrency, or: Go statement considered harmful
#68Earlier quoted context omitted.
The difference is that you can look at function, see it takes no nurseries as parameters, and know it does not spawn any background tasks. And if it does take nurseries, then you know it's likely that it does.
Whats the difference between taking a nursery and returning a promise? Both put the context in the signature, but the later is actually composable.
When I call a function, I have no way of knowing if there are any unhandled promises within it. The difference is the restriction: with nurseries, background tasks can only outlive function calls if the calling function allows them to.
Re: Notes on structured concurrency, or: Go statement considered harmful
#69I thought the title was kinda clickbaity, but it turned out to be a great article. Also the comparison to goto really effectively conveyed the point he was trying to make. I have two questions though: * Does anything else like this currently exist (other than the Trio library he mentions), which shows that it's a superior paradigm in practice? * What are the cons to this approach? Why not do it?
Erlang's concurrency is probably the most similar (greenthreading, channels, messages) and best out there. Errors are handled nicely via supervisor; you can produce a long running fault tolerant system.
Haskell's async[1] solution is very nice too, with the exception restarting processes and fault tolerance isn't really there yet. On the other hand, in Haskell there's stuff like STM, which makes atomic updates to shared memory easy.
At the lower level side of things Rust's model is very nice too. You can statically verify that you don't have certain classes of bugs.
Re: Notes on structured concurrency, or: Go statement considered harmful
#70What. This article proposes a "nursery", which is just a wrapped sync.WaitGroup/pthread_join/futures::future::join_all/a reactor that waits for all tasks to terminate/etc. It then uses an exception-like model for error propagation to "solve" error handling (which is fairly easy to handle with a channel). The construct is a decently usable, already applied tool to handle a set of problems, but the article takes the is…
I thought the article's comparison of go routines to goto was fair, in the context made: when calling a function in a language that allows go-routine like things (including pthread_create), one can't know if background tasks will be spawned. This is similar in the free-form time of unrestricted goto that one could not know if control flow really would return to the point lexically after the function call. His propose…
One can also not "known" of all the other side effect that will happen.
Unless they are documented informally or encoded formally.