Golang co-process and channel finishing _golang

Co-process Goroutine
Instead of being scheduled by the OS, the user layer frees the CPU itself to switch between the execution body. Go at the bottom of the help implementation involves system calls where the Go standard library to help free the CPU in short, not through the OS to switch, the switch, the system running costs greatly reduced

Channel Channel
The key to concurrent programming is the communication between the execution body, go through channel communication channel can be considered similar to other OS system of message queues, but in the live support, so easy to use
What is interesting about Message Queuing. Frequently asked questions include create, close or delete, block, timeout, priority, and Golang are no exception. List as follows: Can detect queues are full or empty.      Or whether you can try to read and write without blocking.      What happens when read blocking and write blocking are closed.      Messages that are not read after they are closed are discarded.      What happens when you send data or read data to a closed channel.      How to detect the closure of channel.      Two places read or write to block the same channel, there is no priority.      Whether you can set the blocking timeout time. How can be bounced out when blocking. Like some sort of signal. In fact, it is important to know that these problems exist and to categorize them, but the answers to these questions are not critical, as they are generally not too outlandish to be used as a temporary test.
Known part of the answer: it seems as if blocking the attempt to read and write shutdown will cause exit blocking (which seems like a nice feature) can detect the shutdown channel itself can not set timeout to understand these seem to be enough.

What's different is worth paying attention to, including: besides basic reading and writing methods, there are some special ways to read and write. What is the difference between blocking, closing, and timing out. Discovered the recommended timeout method for multi-channel read recommended synchronization methods recommended by SELECT, range two keywords


Select
Select to achieve non-blocking multichannel attempts to read and write, as well as blocking timeout var c, C1, C2, C3 Chan int var i1, I2 int
Select  {      Case  i1 = <-c1: //If you can walk through any case, take a random    & Nbsp;    print (  "received", i1,  "from c1\n"  )       Case &NBSP;C2 <-i2:         print (  "Sent", i2,  "to c2\n"         case  i3, OK: = (&LT;-C3):          If & Nbsp;ok {                print (   "Received", i3,  "from c3\n"  )        }  else  { & Nbsp;              print (  "C3 is closed\n ")        }       default: //If case is blocked, Then go to default, if no default, then block in case         //default can not read or write any channel, so long as the default provides not blocking the way out, it is equivalent to achieve the case of non-blocking attempt to read and write          print (  "No Communication\n")}
The way to implement blocking timeouts is to implement a timeout in the case as long as you don't give the default exit
Timeout: = Make (chan bool, 1) go func () {time. Sleep (1E9)//This is wait 1 seconds timeout <-true} ()///timeout this channel as a way out of blocking timeout Select {case &LT;-CH://processing number read from CH According to the case <-timeout://If all blocks, then 1 seconds will find a way out from here}

Range
Range can be read in the For loop the translation of the Channel Go document is: For a channel, its iteration value results in a continuous value sent on that channel until the channel is closed. If the channel is nil, the range expression will always block after the test, the range blocks, and can be unblocked by closing the channel.
Package Main
Import ("FMT")
Func main () {ch: = make (chan int)
Go func () {for i: = 0; i < i++ {ch <-i}
}()
For w: = Range ch {fmt.                    Println ("FMT print", W) if w > 5 {//break//Here Break loops can also Close (CH)}} fmt.  Println ("After range or close ch!" ) }

Golang's concurrent programming has other details, but the above is the main thread.