Since I've been researching reproducible simulation testing recently, and thinking about how to maximize determinism, I was reading this two year old thread.
I had a "lightbulb over the head" moment. I realized _why_ Go's select statement, from CSP, from Dijkstra's guarded commands, is specified to be random. I had been so conditioned by thinking about the client-server model, call and response, the simple model of function invocation and wait for a reply; that I didn't realize the _why_ of select. Then bam. Of course! Otherwise you would get deadlocks everywhere. Even just two goroutines communicating over channels can easily deadlock without a some sort of resolution mechanism. In any arbitrary DAG of communication, you will get deadlocks (dependency cycles), which must be broken somehow, and randomness means the runtime doesn't need any deep knowledge or DAG tracking, so it is a super simple, and effective, solution. It is _almost_ stateless; only the pseudo random number generator's state matters. Just try again on the next loop that wraps the select, and the (previously deadlocked) graph will have (probably) changed. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/b21b5668-a693-4801-a230-73ae61011cc2n%40googlegroups.com.
