4 ms·

Tcl library for Go-style concurrency based on Communicating Sequential Processes

64 points by blacksqr 5y ago

sgt 5y ago
Time to start writing tcl, folks!
monetus 5y ago
"This concurrency model may also be seen as a generalization of Unix named pipes where processes and pipes correspond to coroutines and channels." This is in keeping with tcl, bash, and glue languages - I love this. I'm about to go looking for it, but if anyone can point me to a good reference on Go's concurrency model or it's best practices I would be much obliged.
- sigg3 5y ago
  Effective Go is often thrown around to newcomers such as myself. https://go.dev/doc/effective_go#concurrency https://go.dev/doc/effective_go#concurrency And go by example, of course: https://gobyexample.com/goroutines https://gobyexample.com/goroutines
- hvgk 5y ago
  This is the best reference I found: https://gobyexample.com/goroutines https://gobyexample.com/goroutines Keep reading the next thing until they stop talking about concurrency.
- dradtke 5y ago
  This post might be the most straightforward starting point: https://go.dev/blog/pipelines https://go.dev/blog/pipelines
- avl999 5y ago
  The chapter on channels in Concurrency in Go https://www.oreilly.com/library/view/concurrency-in-go/9781491941294/ https://www.oreilly.com/library/view/concurrency-in-go/97814... is a must read for anyone looking to write concurrent code in Go. There are many "rules" you need to follow with channels to avoid shooting yourself in the foot that I haven't seen summarized in blog posts/official go docs
- sethammons 5y ago
  I recommend rob pike's talk on Go concurrency patterns.
- assbuttbuttass 5y ago
  Great presentation with a lot of examples: https://youtu.be/5zXAHh5tJqQ https://youtu.be/5zXAHh5tJqQ I've used examples from this presentation at work
avl999 5y ago
I'll be slightly contrarian here... the Go concurrency model is not the panacea and channels are overused. It works brilliantly for certain types of usecases (straightforward producer consumer usecases). But unfortunately in the early years of the language there was so dogma pushing people to solely lean on channels and actively avoid traditional concurrency primitives like mutexes and condition variables. Some of that dogma still exists although nowadays "channels are a shotgun that can hurt you" opinion is starting to be more prevalent in the community. I have seen Go code that twists and contorts itself to solely use channels when straightforward mutexes would have made the code easier to understand and reason about. Libraries like this and channels should only be seen as another tool to consider when writing concurrent software rather than treating them like the panacea for concurrent software.
- xh-dude 5y ago
  A subtlety I’m ok with here … channels are a a language primitive but, in terms of runtime, an opinionated composition of data and concurrency semantics; the opinions give the runtime some privilege to do some nice things without a lot of effort when using channels. The misuse of channels in a general sense tends to equate to factoring out of some of the elements composed into the channel primitive. It feels like a lesser sin to use channels in clever ways to recreate mutexes or other patterns than the other way around. But it’s definitely true that they are juiced up to make tradeoffs that are morally wrong for some things.
- somekyle 5y ago
  Yes, overapplying directional advice is a problem, and channels aren't always the right choice, but mutexes/cond vars/atomics have always been part of Go and they've always been listed as viable options, just not usually the best choice for high level coordination. To quote the go1 Effective Go on channel-based interaction: This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance. But as a high-level approach, using channels to control access makes it easier to write clear, correct programs. I'm sure somebody has been banging a "Go programs should never use mutexes" drum, but it hasn't ever been the position of the Go team that channels are a panacea or that mutexes _shouldn't_ be used, as far as I've ever seen.
pjmlp 5y ago
I guess I should drop Tcl's author view on concurrency and threading, https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/ousterhout-threads.pdf https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/... And the HN discussion related to it, https://news.ycombinator.com/item?id=17297325 https://news.ycombinator.com/item?id=17297325
cmacleod4 5y ago
Last update to this was 6 years ago and the documentation links are dead. However from the man page file it seems that this flavour of coroutine cannot be used in the same program as native Tcl coroutines. This would make it useless to me and I suspect to many other people who have an interest in this area.

64 points by blacksqr 5y ago

sgt 5y ago

Time to start writing tcl, folks!

"This concurrency model may also be seen as a generalization of Unix named pipes where processes and pipes correspond to coroutines and channels." This is in keeping with tcl, bash, and glue languages - I love this. I'm about to go looking for it, but if anyone can point me to a good reference on Go's concurrency model or it's best practices I would be much obliged.

sigg3 5y ago
Effective Go is often thrown around to newcomers such as myself. https://go.dev/doc/effective_go#concurrency https://go.dev/doc/effective_go#concurrency And go by example, of course: https://gobyexample.com/goroutines https://gobyexample.com/goroutines
hvgk 5y ago
This is the best reference I found: https://gobyexample.com/goroutines https://gobyexample.com/goroutines Keep reading the next thing until they stop talking about concurrency.
dradtke 5y ago
This post might be the most straightforward starting point: https://go.dev/blog/pipelines https://go.dev/blog/pipelines
avl999 5y ago
The chapter on channels in Concurrency in Go https://www.oreilly.com/library/view/concurrency-in-go/9781491941294/ https://www.oreilly.com/library/view/concurrency-in-go/97814... is a must read for anyone looking to write concurrent code in Go. There are many "rules" you need to follow with channels to avoid shooting yourself in the foot that I haven't seen summarized in blog posts/official go docs
sethammons 5y ago
I recommend rob pike's talk on Go concurrency patterns.
assbuttbuttass 5y ago
Great presentation with a lot of examples: https://youtu.be/5zXAHh5tJqQ https://youtu.be/5zXAHh5tJqQ I've used examples from this presentation at work

avl999 5y ago

I'll be slightly contrarian here... the Go concurrency model is not the panacea and channels are overused. It works brilliantly for certain types of usecases (straightforward producer consumer usecases). But unfortunately in the early years of the language there was so dogma pushing people to solely lean on channels and actively avoid traditional concurrency primitives like mutexes and condition variables. Some of that dogma still exists although nowadays "channels are a shotgun that can hurt you" opinion is starting to be more prevalent in the community. I have seen Go code that twists and contorts itself to solely use channels when straightforward mutexes would have made the code easier to understand and reason about. Libraries like this and channels should only be seen as another tool to consider when writing concurrent software rather than treating them like the panacea for concurrent software.

xh-dude 5y ago
A subtlety I’m ok with here … channels are a a language primitive but, in terms of runtime, an opinionated composition of data and concurrency semantics; the opinions give the runtime some privilege to do some nice things without a lot of effort when using channels. The misuse of channels in a general sense tends to equate to factoring out of some of the elements composed into the channel primitive. It feels like a lesser sin to use channels in clever ways to recreate mutexes or other patterns than the other way around. But it’s definitely true that they are juiced up to make tradeoffs that are morally wrong for some things.
somekyle 5y ago
Yes, overapplying directional advice is a problem, and channels aren't always the right choice, but mutexes/cond vars/atomics have always been part of Go and they've always been listed as viable options, just not usually the best choice for high level coordination. To quote the go1 Effective Go on channel-based interaction: This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance. But as a high-level approach, using channels to control access makes it easier to write clear, correct programs. I'm sure somebody has been banging a "Go programs should never use mutexes" drum, but it hasn't ever been the position of the Go team that channels are a panacea or that mutexes _shouldn't_ be used, as far as I've ever seen.

pjmlp 5y ago

I guess I should drop Tcl's author view on concurrency and threading, https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/ousterhout-threads.pdf https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/... And the HN discussion related to it, https://news.ycombinator.com/item?id=17297325 https://news.ycombinator.com/item?id=17297325

cmacleod4 5y ago

Last update to this was 6 years ago and the documentation links are dead. However from the man page file it seems that this flavour of coroutine cannot be used in the same program as native Tcl coroutines. This would make it useless to me and I suspect to many other people who have an interest in this area.