Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes on structured concurrency, or: Go statement considered harmful

vorpus.org

Post reply on HN
Print view View original

151–160 of 234 posts

Re: Notes on structured concurrency, or: Go statement considered harmful

#151

Post by Animats »

nnq wrote: post #117
Animats wrote: post #113

This addresses the wrong problem. The real issue is control over data shared between threads, not control flow. C/POSIX type threads have no language support for indicating what data is shared and which locks protect which data. That's a common cause of trouble. The big question in shared memory concurrency is "who locks what". Most of the bugs in concurrent programs come from ambiguities over that question. Early at…

> Even the original examples had shared data. But the language didn't provide much support for controlling that sharing. Can you elaborate on this?

Yes, but there will be a service charge.

Re: Notes on structured concurrency, or: Go statement considered harmful

#152

Post by Animats »

kllrnohj wrote: post #147
rumcajz wrote: post #123

Earlier quoted context omitted.

Almost all attempts at CSP-style programming in the end resorted to sharing data to get a little bit better performance. I wonder whether we shouldn't have used a bit of speedup that Moore's law gave us to cover that cost and be done with all the shared state headaches.

Except shared data doesn't give you a little bit better performance, it gives you massively better performance. Or, in some cases, it's the only way to get usable performance at all. Now what you could do is break objects down into annotated types. Consider immutable vs. mutable in combination with thread-unsafe, thread-compatible, and thread-safe. Immutable data that's not thread-unsafe you can share freely across t…

I proposed something like that for Python in 2010.[1] Immutable objects could be shared. Mutable objects had to either be unshared, or a subclass of an object that enforced synchronization.

Python's Little Tin God didn't like it. Mostly because I proposed to freeze the code of the program once the second thread started. That takes away much of the dynamism he insists on.

Might be worth looking at again. The separation of data into immutable, unshared, or synchronized is mainstream now.

[1] http://animats.com/papers/languages/pythonconcurrency.html

Re: Notes on structured concurrency, or: Go statement considered harmful

#153

Post by noxecanexx »

arghwhat wrote: post #27
scott_s wrote: post #24

Earlier quoted context omitted.

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…

Knowing whether a background task has spawned is very different from not being able to follow the control flow (goto potentially jumping to an entirely different function body). Now, while Go is designed mostly for you to not care about goroutines, there are some corner cases where one must know if a resource is used by anything, such as the chase of when you wish to close a file handle. However, I'd argue that this…

This is very true. The same way one doesn't know if a background was started is the same way you can't know if a file was written to or some global state was changed. I thought async/await solves most of his examples

Re: Notes on structured concurrency, or: Go statement considered harmful

#154

Post by jnwatson »

What timing!

My project is currently struggling with how to migrate to Python async. The biggest challenge is the place where async and sync interface.

Just the other day, my colleague was wondering out loud about the possibility of using a context manager to constrain the scope of async. This is it. This is exactly what we were looking for.

Re: Notes on structured concurrency, or: Go statement considered harmful

#155

Post by ellyagg »

arghwhat wrote: post #19

What. 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…

Can I just mention that anyone who begins their comment with

    What.
...and:

    [whatever] is just a [whatever]
...comes across as a bit of an asshole?

Why not just make your point instead of investing a lot in making sure everyone knows that you're smart and the other person is dumb?

Maybe Knuth was just as rude to Dijkstra, who knows?

Re: Notes on structured concurrency, or: Go statement considered harmful

#156

Post by eridius »

coldtea wrote: post #141
lilyball wrote: post #86

Earlier quoted context omitted.

> Author is a PhD student, which bodes well for not reinventing wheels dumbly. Except that's exactly what the author did. They just reinvented scoped threadpools.

In the sense that a car is a reinvention of a horse buggy.

In what way? Nurseries sound like they're exactly the same thing as a Rust scoped threadpool with a 'static lifetime. Not some sort of super modernization like you're suggesting.

Re: Notes on structured concurrency, or: Go statement considered harmful

#157

Post by [deleted] »

Osiris wrote: post #146

> whenever you call a function, it might or might not spawn some background task. The function seemed to return, but is it still running in the background? There's no way to know without reading all its source code, transitively. When will it finish? Hard to say. This reminds of me "colored functions" (red vs blue) where it becomes imperative to know if a function you are calling returns a value or a Future/Promise.…

[deleted]

Re: Notes on structured concurrency, or: Go statement considered harmful

#158

Post by coldtea »

It's amazing how many people managed to skim through the post, and hammer on their own preconceptions and facile counter-arguments, for things that are all addressed in the argument.

And that's for a very well written post, that tries to address all common issues.

And yet, people manage to get it wrong, or write facile responses like "re-implementing the fork/join".

Not to mention missing the whole nuance of what the author is talking about, which is not about novelty of a feature, but about what it allows us (and even more so, what it constraints us).

It's like as if people being shown for loops and structured programming in the 60s responded with "this proposal just reinvents gotos". Or worse, that "this is more restrictive that gotos".

Yes, the author knows about the Erlang's model. He writes about it in the post, and about how you can use his proposal to do something similar.

Yes, the author knows about Rust's model. In fact Graydon Hoare, the creator of Rust (now working at Apple on Swift), has read the post's initial draft and gave his comments to the author.

Re: Notes on structured concurrency, or: Go statement considered harmful

#160

Post by fixermark »

arghwhat wrote: post #19

What. 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…

> It then uses an exception-like model for error propagation to "solve" error handling (which is fairly easy to handle with a channel).

If none of your code ever actually waits on the error channel when you spawn a goroutine, what happens?

Is there any circumstance where that behavior is preferable to guaranteeing something must wait on the error channel?

Post reply on HN