When your main() function ends, your program ends as well. It does not wait for other goroutines to finish. Quoting from the Go Language Specification: Program Execution: Program execution begins by initializing the main package and then invoking the function main. When that function invocation returns, the program exits. It does not wait for other … Read more
Note that one interesting aspect of using struct{} for the type pushed to a channel (as opposed to int or bool), is that the size of an empty struct is… 0! See the recent article “The empty struct” (March 2014) by Dave Cheney. You can create as many struct{} as you want (struct{}{}) to push … Read more
From the Go Language Spec: For a channel c, the built-in function close(c) records that no more values will be sent on the channel. It is an error if c is a receive-only channel. Sending to or closing a closed channel causes a run-time panic. Closing the nil channel also causes a run-time panic. After … Read more
In Go no value is safe for concurrent read/write, slices (which are slice headers) are no exception. Yes, your code has data races. Run with the -race option to verify. Example: type myClass struct { AttributeName string } sourceSlice := make([]myClass, 100) destSlice := make([]myClass, 0) var wg sync.WaitGroup for _, myObject := range sourceSlice … Read more
I think what you are looking for is Control.Concurrent.Chan from Base. I haven’t found it to be any different from go’s chans other then the obvious haskellifications. Channels aren’t something that is special to go, have a look at the wiki page about it. Channels are part of a more general concept called communicating sequential … Read more
“Sleeping” You can use numerous constructs that block forever without “eating” up your CPU. For example a select without any case (and no default): select{} Or receiving from a channel where nobody sends anything: <-make(chan int) Or receiving from a nil channel also blocks forever: <-(chan int)(nil) Or sending on a nil channel also blocks … Read more
The Go spec says: A “break” statement terminates execution of the innermost “for”, “switch”, or “select” statement within the same function. In your example you’re just breaking out of the select statement. If you replace break with a return statement you will see that it’s working.
If you remove the time.Sleep you don’t give the say(“world”) goroutine a chance to run. The goroutine scheduler is not preemptive. Your goroutines have to give up control before another goroutine will run. One way to give up control is to run time.Sleep. If you take out the time.Sleep from the say function then the … Read more
Yes, increasing the buffer size might drastically increase the execution speed of your program, because it will reduce the number of context switches. Goroutines aren’t garbage-collected, but channels are. In your example, the fibonacci goroutine will run forever (waiting for another goroutine to read from the channel c), and the channel c will never be … Read more
I think you need to change your max file descriptors. I have run into the same problem on one of my development VMs before and needed to change the file descriptors max, not anything with inotify settings. FWIW, your program runs fine on my VM. ·> ulimit -n 120000 But after I run ·> ulimit … Read more