如何根據該例程的返回值來停止goroutine

Question

像這裏一樣，我創建了一個go playground示例：sGgxEh40ev，但無法使其工作。

quit := make(chan bool) 
res := make(chan int) 

go func() { 
    idx := 0 
    for { 
     select { 
     case <-quit: 
      fmt.Println("Detected quit signal!") 
      return 
     default: 
      fmt.Println("goroutine is doing stuff..") 
      res <- idx 
      idx++ 
     } 
    } 

}() 

for r := range res { 
    if r == 6 { 
     quit <- true 
    } 
    fmt.Println("I received: ", r) 
} 

輸出：

goroutine is doing stuff.. 
goroutine is doing stuff.. 
I received: 0 
I received: 1 
goroutine is doing stuff.. 
goroutine is doing stuff.. 
I received: 2 
I received: 3 
goroutine is doing stuff.. 
goroutine is doing stuff.. 
I received: 4 
I received: 5 
goroutine is doing stuff.. 
goroutine is doing stuff.. 
fatal error: all goroutines are asleep - deadlock! 

這可能嗎？我錯在哪裏

Answer 1

問題是在goroutine中你使用select來檢查它是否應該中止，但是你使用default分支，否則做的工作。

如果沒有通信（在case分支中列出）可以繼續執行，則會執行default分支。因此，在每次迭代中，quit通道都被檢查，但是如果無法接收到（不需要退出），default分支被執行，其中無條件地試圖發送res上的值。現在，如果主辦公室不準備接收它，這將是一個僵局。當發送的值爲6時，這正是發生的情況，因爲然後主goroutine嘗試發送quit上的值，但是如果工作程序goroutine在default分支嘗試發送res，然後兩個goroutines嘗試發送價值，沒有人試圖收到！這兩個頻道都是無緩衝的，所以這是一個僵局。

在工人夠程，你必須res使用適當的case分支發送值，而不是在default分支：

select { 
case <-quit: 
    fmt.Println("Detected quit signal!") 
    return 
case res <- idx: 
    fmt.Println("goroutine is doing stuff..") 
    idx++ 
} 

，並在主夠程，你必須從for循環，這樣的爆發主夠程可以結束，因此該程序可以結束，以及：

if r == 6 { 
    quit <- true 
    break 
} 

輸出這次（嘗試在Go Playground）：

goroutine is doing stuff.. 
I received: 0 
I received: 1 
goroutine is doing stuff.. 
goroutine is doing stuff.. 
I received: 2 
I received: 3 
goroutine is doing stuff.. 
goroutine is doing stuff.. 
I received: 4 
I received: 5 
goroutine is doing stuff.. 
goroutine is doing stuff.. 

Answer 2

最根本的問題是，如果消費者（你的情況下主）已決定退出閱讀（在你的代碼中這是可選的），生產者必須在發送值之間簽入總是。發生了什麼事情甚至在發送（和接收）退出的值之前，生產者繼續併發送消費者永遠無法讀取的res上的下一個值 - 消費者實際上試圖在退出通道上發送值期待制片人閱讀。添加了一條調試語句，可以幫助您理解：https://play.golang.org/p/mP_4VYrkZZ， - 生產者試圖發送res和阻止數據，然後，然後使用者試圖發送退出和阻止值。僵局！

一個可能的解決方案如下（使用Waitgroup是可選的，如果你需要從製片方乾淨退出返回之前僅需要）：

package main 

import (
    "fmt" 
    "sync" 
) 

func main() { 
    //WaitGroup is needed only if need a clean exit for producer 
    //that is the producer should have exited before consumer (main) 
    //exits - the code works even without the WaitGroup 
    var wg sync.WaitGroup 
    quit := make(chan bool) 
    res := make(chan int) 

    go func() { 
     idx := 0 
     for { 

      fmt.Println("goroutine is doing stuff..", idx) 
      res <- idx 
      idx++ 
      if <-quit { 
       fmt.Println("Producer quitting..") 
       wg.Done() 
       return 
      } 

      //select { 
      //case <-quit: 
      //fmt.Println("Detected quit signal!") 
      //time.Sleep(1000 * time.Millisecond) 
      // return 
      //default: 
      //fmt.Println("goroutine is doing stuff..", idx) 
      //res <- idx 
      //idx++ 
      //} 
     } 


    }() 
    wg.Add(1) 
    for r := range res { 
     if r == 6 { 
      fmt.Println("Consumer exit condition met: ", r) 
      quit <- true 
      break 
     } 
     quit <- false 
     fmt.Println("I received: ", r) 
    } 
    wg.Wait() 

} 

輸出：

goroutine is doing stuff.. 0 
I received: 0 
goroutine is doing stuff.. 1 
I received: 1 
goroutine is doing stuff.. 2 
I received: 2 
goroutine is doing stuff.. 3 
I received: 3 
goroutine is doing stuff.. 4 
I received: 4 
goroutine is doing stuff.. 5 
I received: 5 
goroutine is doing stuff.. 6 
Consumer exit condition met: 6 
Producer quitting.. 

操場：https://play.golang.org/p/N8WSPvnqqM

Answer 3

由於@ icza的回答很乾淨，@ Ravi的採用了同步的方式。

但是怎麼我不想花那麼多精力進行重組的代碼，我也不想去同步的方式，所以最終去了defer panic recover流量控制，如下：

func test(ch chan<- int, data []byte) { 
    defer func() { 
     recover() 
    }() 
    defer close(ch) 

    // do your logic as normal ... 
    // send back your res as normal `ch <- res` 
} 

// Then in the caller goroutine 

ch := make(chan int) 
data := []byte{1, 2, 3} 
go test(ch, data) 

for res := range ch { 
    // When you want to terminate the test goroutine: 
    //  deliberately close the channel 
    // 
    // `go -race` will report potential race condition, but it is fine 
    // 
    // then test goroutine will be panic due to try sending on the closed channel, 
    //  then recover, then quit, perfect :) 
    close(ch) 
    break 
} 

這種方法的潛在風險？