How do goroutines map to native OS threads? How do they get scheduled? It all seems a bit magical to me - which is great when things work as expected...
Is it really any more magical than how OS threads get mapped to CPU cores?
Intro to images in Go – concurrency
11–18 of 18 posts
Re: Intro to images in Go – concurrency
#12These posts are great, pheelicks, keep it up! Your previous post inspired me to make this: http://github.com/lukechampine/algo
My 3D renderer still suffers from faulty compositing (polygons are rendered in arbitrary order, instead of according to their respective depths) but I like being able to see an animated result instead of just a static image.
Re: Intro to images in Go – concurrency
#13This is probably a stupid question, but is the Canvas's DrawLine function thread-safe? It looks like multiple Nodes could be drawing to the same canvas at the same time, and I don't see any locks/mutexes/whatevers wrapping that call.
Obviously it can't be too much of a big deal, since the (very nifty) example works just fine, but I'm curious about what's going on here.
Re: Intro to images in Go – concurrency
#14Nice visuals! But this highlights one thing about Go that irks me coming from Erlang: sending mutable state over channels. Here the power of a node is modified in another nodes goroutine, which makes things much trickier to reason about. A better approach, IMO, would be to decrement the power before a node sends itself over a channel.
I have the same feeling. Have you checked Rust? It is a different approach where ownership and mutability are strictly controlled via the type system.
Re: Intro to images in Go – concurrency
#15This is probably a stupid question, but is the Canvas's DrawLine function thread-safe? It looks like multiple Nodes could be drawing to the same canvas at the same time, and I don't see any locks/mutexes/whatevers wrapping that call. Obviously it can't be too much of a big deal, since the (very nifty) example works just fine, but I'm curious about what's going on here.
I'm a noob at concurrent programming, but from what I can tell, the only concurrent mutation is when setting the pixels, in image.go:
94 p.Pix[i+0] = c1.R
95 p.Pix[i+1] = c1.G
96 p.Pix[i+2] = c1.B
97 p.Pix[i+3] = c1.A
Re: Intro to images in Go – concurrency
#16How do goroutines map to native OS threads? How do they get scheduled? It all seems a bit magical to me - which is great when things work as expected...
The Go runtime has a built-in scheduler which historically would be called into action for possible preemption whenever an OS system call is made or could be invoked manually in Go code via runtime.Gosched(). Go 1.2 added a change allowing the scheduler to possibly be kicked off during any Go language function call which reduces the likelihood of being locked in a tight loop that never makes a system call.
There are obviously still cases where you can trap yourself into a deadlock by tight looping in code that makes no function calls at all, but it is pretty easy to detect this and adjust for it.
Re: Intro to images in Go – concurrency
#17Nice visuals! But this highlights one thing about Go that irks me coming from Erlang: sending mutable state over channels. Here the power of a node is modified in another nodes goroutine, which makes things much trickier to reason about. A better approach, IMO, would be to decrement the power before a node sends itself over a channel.
I have the same feeling. Have you checked Rust? It is a different approach where ownership and mutability are strictly controlled via the type system.
Yep, I'm very excited about Rust. I think per task/process heaps is really key to getting concurrency and reliability done right. Also the type system and aim for zero cost abstractions seems great. That said, it is still pretty early stage so I'm holding off for the 1.0 release.
Re: Intro to images in Go – concurrency
#18There was another post here on HN about Go and working with images, the author was very impressed with the standard library because it could do a lot with images. Unfortunately, I have tried to search for the article but I can't find it.
Was it this submission? Same blog, a few weeks back. https://news.ycombinator.com/item?id=6542082
Yes! Thats it! Thanks, this is now bookmarked.