在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)函数的末尾使用main，它将退出/终止正在运行的命令。

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

在尝试使用单个goroutine时，我尝试了以下操作：https://play.golang.org/p/r7IuEtSM-gL，但是cmd.Wait()似乎一直在select处于阻塞状态，并且无法调用{{ 1}}

Answer 1

在Go中，如果到达main方法包（在main中）的结尾，程序将停止。这种行为在Go语言规范的section on program execution下进行了描述（强调我自己的意思）：

  

程序执行从初始化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子进程将为orphaned；在Unix系统上，操作系统通常会将进程重新建立到init进程的父级。

单个goroutine示例

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

• 在cmd.Wait方法中对Run的调用是阻塞调用（docs）。 select语句被阻止，等待cmd.Wait返回错误值，因此无法从quit通道接收。

• quit频道（在ch中声明为main）是无缓冲频道。在未缓冲的通道上的发送操作将阻塞，直到接收器准备好接收数据为止。从language spec on channels（再次强调一下，我自己的话）：

    

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

  由于Run被cmd.Wait阻塞，因此没有现成的接收器来接收ch <- struct{}{}方法中的main语句在通道上发送的值。 main阻止等待传输此数据，从而阻止进程返回。

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

cmd.Wait正在阻止

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

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来执行{ {1}}阻止通话。

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

Done

（Playground link）