doulei6778
2018-05-18 08:07
浏览 19
已采纳

在Go中收到SIGINT时是否调用了延迟函数?

For the snippet below, the deferred call is not made when ^C is received. Is it possible that the cleanup introduces a race condition? If yes, what could be a better pattern of cleanup on receiving an interrupt?

  func fn() {
    // some code
    defer cleanup()
    go func() {
       c := make(chan os.Signal, 1)
       signal.Notify(c, os.Interrupt)

       // Block until a signal is received.
       _ = <-c
       cleanup()
     }
     for {
        // Infinite loop. Returns iff an error is encountered in the 
        // body
     }
}
  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • dongqia0240 2018-05-18 08:43
    已采纳

    Note that if you "install" your signal channel with signal.Notify(), the default behavior will be disabled. This means if you do this, the for loop in your fn() function will not be interrupted, it will continue to run.

    So when you receive a value on your registered channel, you have to make that for loop terminate so you can do a "clean" cleanup. Else the resources cleanup() ought to free might still be used in for, most likely resulting in error or panic.

    Once you do this, you don't even have to call cleanup() manually, because returning from fn() will run the deferred function properly.

    Here's an example:

    var shutdownCh = make(chan struct{})
    
    func fn() {
        defer cleanup()
    
        go func() {
            c := make(chan os.Signal, 1)
            signal.Notify(c, os.Interrupt)
            <-c
            close(shutdownCh)
        }()
    
        for {
            select {
            case <-shutdownCh:
                return
                // Other cases might be listed here..
            default:
            }
            time.Sleep(time.Millisecond)
        }
    }
    

    Of course the above example does not guarantee app termination. You should have some code that listens to the shutdownCh and terminates the app. This code should also wait for all goroutines to gracefully finish. For that you may use sync.WaitGroup: add 1 to it when you launch a goroutine that should be waited for on exit, and call WaitGroup.Done() when such a goroutine finishes.

    Also since in a real app there might be lots of these, the signal handling should be moved to a "central" place and not done in each place.

    Here's a complete example how to do that:

    var shutdownCh = make(chan struct{})
    var wg = &sync.WaitGroup{}
    
    func main() {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fn()
        }()
    
        c := make(chan os.Signal, 1)
        signal.Notify(c, os.Interrupt)
        <-c
        close(shutdownCh)
        wg.Wait()
    }
    
    func fn() {
        defer cleanup()
        for {
            select {
            case <-shutdownCh:
                return
                // Other cases might be listed here..
            default:
            }
            fmt.Println("working...")
            time.Sleep(time.Second)
        }
    }
    
    func cleanup() {
        fmt.Println("cleaning up...")
    }
    

    Here's an example output of the above app, when pressing CTRL+C 3 seconds after its start:

    working...
    working...
    working...
    ^Ccleaning up...
    
    点赞 评论

相关推荐 更多相似问题