Re: [pop-dev] Go - a new language from Google

[Rick Beton <rick.beton@xxxxxxxxx>]

Ahah! I think I understand Goroutines now - please would those who know all this just bear with me. I thought I'd share what I just learnt for the benefit of anyone else who hasn't happened on this yet.

The FAQ is reasonably clear - http://golang.org/doc/go_lang_faq.html#goroutines

So, Go has a thread pool maintained by the runtime - these are real operating system threads (or similar) but the programmer doesn't see them. The program's goroutines are not threads. Goroutines each live in their own stack space, and they get executed by threads from the pool when they aren't blocked on channel i/o etc. The runtime has a scheduler that assigns goroutines to threads according to some scheduling algorithm.

Of course, under the hood, a single processor implementation will itself schedule cpu time to each of those threads according to some (different) scheduling algorithm. And a multicore is a bit more of the same.

So, if I'm right, there's a double layer of scheduling. This probably makes a lot of sense in the target audience for Go, using operating systems whose threads are not known for being lightweight in memory footprint nor creation/deletion time. Indeed thread pools are one of the first things that most object oriented language programmers of my acquaintance reach for when they want to do a large number of concurrent things but know that their favourite language (usually Java amongst colleagues of mine) gets quite messy quite soon when too many threads are used. That loosely justifies the Go approach, and illustrates quite a significant difference from the Kroc/Toc execution model using genuinely-lightweight processes.

Regards,
Rick