在goroutine中使用exec.CommandContext时如何调用cancel（）

Question

我想按需取消正在运行的命令，为此，我正在尝试exec.CommandContext，目前正在尝试这样做：

https://play.golang.org/p/0JTD9HKvyad

    package main

    import (
        "context"
        "log"
        "os/exec"
        "time"
    )

    func Run(quit chan struct{}) {
        ctx, cancel := context.WithCancel(context.Background())
        cmd := exec.CommandContext(ctx, "sleep", "300")
        err := cmd.Start()
        if err != nil {
            log.Fatal(err)
        }

        go func() {
            log.Println("waiting cmd to exit")
            err := cmd.Wait()
            if err != nil {
                log.Println(err)
            }
        }()

        go func() {
            select {
            case <-quit:
                log.Println("calling ctx cancel")
                cancel()
            }
        }()
    }

    func main() {
        ch := make(chan struct{})
        Run(ch)
        select {
        case <-time.After(3 * time.Second):
            log.Println("closing via ctx")
            ch <- struct{}{}
        }
    }

我面临的问题是cancel()被调用了，但是进程没有被杀死，我的猜测是主线程首先退出，并且不等待cancel()正确终止命令，主要是因为如果我time.Sleep(time.Second)在末尾使用a
在的main退出功能/杀死正在运行的命令。

关于如何wait在退出不使用sleep？之前确保命令已被杀死的任何想法？cancel()成功杀死命令后，可以在通道中使用它吗？

在尝试使用单个goroutine的过程中，我尝试了以下操作：https :
//play.golang.org/p/r7IuEtSM-gL，但cmd.Wait()似乎一直在阻塞，select并且无法调用cancel()

Answer 1

在Go中，如果到达main方法的结尾（在main包中），程序将停止。Go语言规范中有关程序执行的部分（强调我自己）中描述了此行为：

程序执行首先初始化main程序包，然后调用函数main。当该函数调用返回时，程序退出。 它不等待其他（非主）goroutine完成。

我将考虑您的每个示例及其相关的控制流缺陷。您会在下面找到“转到游乐场”的链接，但由于sleep找不到可执行文件，因此这些示例中的代码将不会在限制性游乐场沙箱中执行。复制并粘贴到您自己的环境中进行测试。

多个goroutine示例

    case <-time.After(3 * time.Second):
            log.Println("closing via ctx")
            ch <- struct{}{}

计时器触发后，您向goroutine发出信号，是时候杀死孩子并停止工作了，没有什么main可以阻止该方法并等待该方法完成的，所以它返回。根据语言规范，程序退出。

调度程序可能会在频道传输后触发，因此在main退出与其他goroutine唤醒以从接收信号之间可能存在竞争ch。但是，假设行为有任何特定的交织是不安全的-
出于实际目的，在main退出前不太可能进行任何有用的工作。该sleep子进程将被孤立
; 在Unix系统上，操作系统通常会将进程重新建立父init进程。

单个goroutine示例

在这里，您面临相反的问题：main不返回，因此子进程不会被杀死。仅在子进程退出时（5分钟后）才能解决这种情况。发生这种情况是因为：

• 该呼叫cmd.Wait在Run方法是一个阻塞呼叫（文档）。该select语句被阻塞，等待cmd.Wait返回错误值，因此无法从quit通道接收。
• 的quit信道（声明为ch在main）是一种 无缓冲通道 。在未缓冲的通道上的发送操作将阻塞，直到接收器准备好接收数据为止。从渠道的语言规范（再次强调自己）：

容量（以元素数为单位）设置通道中缓冲区的大小。如果容量为零或不存在，则通道没有缓冲，并且 仅在发送方和接收方都准备就绪时通信才能成功 。

如中Run所阻止cmd.Wait，没有就绪的接收器可以接收方法中的ch <- struct{}{}语句在通道上传输的值main。main块等待传输此数据，从而防止进程返回。

我们可以通过较小的代码调整来演示这两个问题。

cmd.Wait 正在阻止

要暴露的阻塞性质cmd.Wait，请声明以下函数并在Wait调用中使用它。此函数是一个包装程序，具有与相同的行为cmd.Wait，但是还有其他副作用，可以打印STDOUT发生的情况。（Playground链接）：

    func waitOn(cmd *exec.Cmd) error {
        fmt.Printf("Waiting on command %p\n", cmd)
        err := cmd.Wait()
        fmt.Printf("Returning from waitOn %p\n", cmd)
        return err
    }

    // Change the select statement call to cmd.Wait to use the wrapper
    case e <- waitOn(cmd):

运行此修改后的程序后，您将观察Waiting on command <pointer>到控制台的输出。计时器启动后，您将观察到输出calling ctx cancel，但没有相应的Returning from waitOn <pointer>文本。这只会在子进程返回时发生，您可以通过将睡眠时间减少到较小的秒数（我选择5秒）来快速观察。

在退出频道上发送ch，阻止

main无法返回，因为用于传播退出请求的信号通道是未缓冲的，并且没有相应的侦听器。通过更改行：

    ch := make(chan struct{})

至

    ch := make(chan struct{}, 1)

通道上的发送main将继续（到达通道的缓冲区）并main退出-
与多goroutine示例相同的行为。但是，此实现仍然失败：将不会从通道的缓冲区读取该值，而实际上不会在main返回之前开始停止子进程，因此该子进程仍将被孤立。

固定版

我为您制作了一个固定版本，代码如下。还有一些样式上的改进，可以将您的示例转换为更惯用的语言：

• 当需要停止时，不需要通过通道间接发出信号。相反，我们可以通过将上下文声明和取消函数悬挂到该main方法来避免声明通道。可以在适当的时间直接取消上下文。

我保留了单独的Run函数来演示以这种方式传递上下文，但是在许多情况下，可以将其逻辑嵌入到main方法中，并生成一个goroutine来执行cmd.Wait阻塞调用。

• 该方法中的select语句main是不必要的，因为它只有一个case语句。
• sync.WaitGroup引入来明确解决在main终止子进程（在单独的goroutine中等待）之前退出的问题。等待组实现一个计数器；在Wait所有goroutine完成工作并被调用之前，对块的调用Done。

    package main

    import (
        "context"
        "log"
        "os/exec"
        "sync"
        "time"
    )

    func Run(ctx context.Context) {
        cmd := exec.CommandContext(ctx, "sleep", "300")
        err := cmd.Start()
        if err != nil {
            // Run could also return this error and push the program
            // termination decision to the `main` method.
            log.Fatal(err)
        }

        err = cmd.Wait()
        if err != nil {
            log.Println("waiting on cmd:", err)
        }
    }

    func main() {
        var wg sync.WaitGroup
        ctx, cancel := context.WithCancel(context.Background())

        // Increment the WaitGroup synchronously in the main method, to avoid
        // racing with the goroutine starting.
        wg.Add(1)
        go func() {
            Run(ctx)
            // Signal the goroutine has completed
            wg.Done()
        }()

        <-time.After(3 * time.Second)
        log.Println("closing via ctx")
        cancel()

        // Wait for the child goroutine to finish, which will only occur when
        // the child process has stopped and the call to cmd.Wait has returned.
        // This prevents main() exiting prematurely.
        wg.Wait()
    }

（游乐场链接）