Questions in golang
harrysun · · 3921 次点击 · · 开始浏览I list some questions in Go in my daily life and the corresponding answer.
QA 1. the reader <-channel will be blocked until the writer write the channel?
in gocrawl, the worker reads the channel as follows
1 select { 2 case <-this.stop: 3 this.logFunc(LogInfo, "stop signal received.") 4 return 5 default: 6 // Nothing, just continue... 7 }
However, I can't find the code where the crawler writes the chanel but only to find code illustrated below
1 for { 2 // By checking this after each channel reception, there is a bug if the worker 3 // wants to reenqueue following an error or a redirection. The pushPopRefCount 4 // temporarily gets to zero before the new URL is enqueued. Check the length 5 // of the enqueue channel to see if this is really over, or just this temporary 6 // state. 7 // 8 // Check if refcount is zero - MUST be before the select statement, so that if 9 // no valid seeds are enqueued, the crawler stops. 10 if this.pushPopRefCount == 0 && len(this.enqueue) == 0 { 11 this.logFunc(LogInfo, "sending STOP signals...") 12 close(this.stop) 13 return nil 14 } 15 ......
I am puzzed about it and wonder does close chanel will make <-channel work. So I make a test ad demenstrated
1 package main 2 3 import ( 4 "fmt" 5 "sync" 6 "time" 7 ) 8 9 func worker(wg *sync.WaitGroup, c <-chan int) { 10 fmt.Println("begin worker") 11 12 time.Sleep(1e9) 13 temp, ok := <-c 14 fmt.Printf("read singal : %d and ok= %t \n", temp, ok) 15 wg.Done() 16 17 fmt.Println("end worker") 18 } 19 20 func main() { 21 fmt.Println("begin main") 22 23 var wg sync.WaitGroup 24 wg.Add(1) 25 26 cint := make(chan int, 1) 27 go worker(&wg, cint) 28 time.Sleep(3e9) 29 fmt.Println("close channel in main") 30 close(cint) 31 32 wg.Wait() 33 34 fmt.Println("end main") 35 }
the result is
conclusion:
if the writter calls close(channel), the reader with expression v, ok := <-channel will get v=0 and ok=false.
ok= false means the channel is closed.
the writer closing the channel makes the reader "read" the value 0 from the channel.
after further thought, I find that close(channel) boardcast the signal to all the readers, which is a good mechanism.
in the case of gocrawler, the master can boardcast the "stop" signal to all its workers just use only one chan "stop chan struct{}" instead of using "map[host] chan struct{}" for each of the worker.
有疑问加站长微信联系(非本文作者)
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
关注微信- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码` - 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传
收入到我管理的专栏 新建专栏
I list some questions in Go in my daily life and the corresponding answer.
QA 1. the reader <-channel will be blocked until the writer write the channel?
in gocrawl, the worker reads the channel as follows
1 select { 2 case <-this.stop: 3 this.logFunc(LogInfo, "stop signal received.") 4 return 5 default: 6 // Nothing, just continue... 7 }
However, I can't find the code where the crawler writes the chanel but only to find code illustrated below
1 for { 2 // By checking this after each channel reception, there is a bug if the worker 3 // wants to reenqueue following an error or a redirection. The pushPopRefCount 4 // temporarily gets to zero before the new URL is enqueued. Check the length 5 // of the enqueue channel to see if this is really over, or just this temporary 6 // state. 7 // 8 // Check if refcount is zero - MUST be before the select statement, so that if 9 // no valid seeds are enqueued, the crawler stops. 10 if this.pushPopRefCount == 0 && len(this.enqueue) == 0 { 11 this.logFunc(LogInfo, "sending STOP signals...") 12 close(this.stop) 13 return nil 14 } 15 ......
I am puzzed about it and wonder does close chanel will make <-channel work. So I make a test ad demenstrated
1 package main 2 3 import ( 4 "fmt" 5 "sync" 6 "time" 7 ) 8 9 func worker(wg *sync.WaitGroup, c <-chan int) { 10 fmt.Println("begin worker") 11 12 time.Sleep(1e9) 13 temp, ok := <-c 14 fmt.Printf("read singal : %d and ok= %t \n", temp, ok) 15 wg.Done() 16 17 fmt.Println("end worker") 18 } 19 20 func main() { 21 fmt.Println("begin main") 22 23 var wg sync.WaitGroup 24 wg.Add(1) 25 26 cint := make(chan int, 1) 27 go worker(&wg, cint) 28 time.Sleep(3e9) 29 fmt.Println("close channel in main") 30 close(cint) 31 32 wg.Wait() 33 34 fmt.Println("end main") 35 }
the result is
conclusion:
if the writter calls close(channel), the reader with expression v, ok := <-channel will get v=0 and ok=false.
ok= false means the channel is closed.
the writer closing the channel makes the reader "read" the value 0 from the channel.
after further thought, I find that close(channel) boardcast the signal to all the readers, which is a good mechanism.
in the case of gocrawler, the master can boardcast the "stop" signal to all its workers just use only one chan "stop chan struct{}" instead of using "map[host] chan struct{}" for each of the worker.