> show how to easily trigger races & deadlocks? I mean, the Go team needs to be aware of these problems and provide a fix or something.
You mean file a bug like "issue #1935 -- stop sharing memory between goroutines" (I just made it up to be silly there is no such bug report)
In other words, they have explicitly designed in the ability to share memory between goroutines. You can certainly file an issue or bug report about, somehow I doubt that will lead to much but being kickout and laughed at.
One can also just have 2 goroutines wait on each for results and that's a deadlock. Maybe there is a tool to detect that would be nice. Do you know of one?
If all goroutines deadlock, then the runtime will panic and you'll get stack traces for everything. But yes, you can obviously deadlock one or more goroutines trivially. A simple select{} will just block one goroutine forever, for example. And no, there's no tools currently that will detect deadlocks, AFAIK.
I haven't looked into that (or googled), but how does one detect that everything has deadlocked - is it some kind of profiling/sampling being done, or is it something more system specific? Any pointers? Thanks!
http://golang.org/pkg/runtime/pprof/#Profile
Provides a "blocking profile" that tells you what things blocked and for how long they blocked for.
You can use it to find places where you've deadlocked as well as places where adding buffered channels might help performance.
You mean file a bug like "issue #1935 -- stop sharing memory between goroutines" (I just made it up to be silly there is no such bug report)
In other words, they have explicitly designed in the ability to share memory between goroutines. You can certainly file an issue or bug report about, somehow I doubt that will lead to much but being kickout and laughed at.
One can also just have 2 goroutines wait on each for results and that's a deadlock. Maybe there is a tool to detect that would be nice. Do you know of one?