Any channel that is left waiting and/or left receiving will result in a deadlock. Luckily, Go is pretty adept at recognizing these and you will almost without fail end up in a panic when running or building the application.
Many of our examples so far have utilized the deferred close() method of immediately and cleanly grouping together similar pieces of code that should execute at different points.
While garbage collection handles a lot of the cleanup, we're largely left to take care of open channels to ensure we don't have a process waiting to receive and/or something waiting to send, both waiting at the same time for each other. Luckily, we'll be unable to compile any such program with a detectable deadlock condition, but we also need to manage closing channels that are left waiting.
Quite a few of the examples so far have ended with a generic integer or Boolean channel that just waits—this is employed almost exclusively for the channel's blocking effect and allows us to demonstrate the effects and output of concurrent code while the application is still running. In many cases, this generic channel is an unnecessary bit of syntactical cruft as shown in the following lines of code:
<-youMayNotNeedToDoThis close(youmayNotNeedToDoThis)
The fact that there's no assignment happening is a good indicator this is an example of such cruft. If we had instead modified that to include an assignment, the previous code would be changed to the following instead:
v := <-youMayNotNeedToDoThis
It might indicate that the value is useful and not just arbitrary blocking code.
If you run the code from our earlier chat server's client without starting the server, you'll notice that the Dial function blocks any subsequent goroutine. We can test this by imposing a longer-than-normal timeout on the connection or by simply closing the client application after logging in, as we did not implement a method for closing the TCP connection.
As the network reader we're using for the connection is buffered, we'll always have a blocking mechanism while waiting for data via TCP.