在 goroutine 中使用 exec.CommandContext 时如何调用 cancel()

nba*_*ari 4 go

我想按需取消正在运行的命令,为此,我正在尝试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{}{}
    }
}
Run Code Online (Sandbox Code Playgroud)

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

关于如何wait确保在不使用 a 退出之前已终止该命令的任何想法sleep?可以在cancel()一个通道中使用已成功地杀死了命令之后?

在尝试使用单个 goroutine 时,我尝试了这个:https : //play.golang.org/p/r7IuEtSM-gLcmd.Wait()似乎一直在阻塞select并且无法调用cancel()

Cos*_*age 8

在 Go 中,如果到达main方法的末尾(在main包中),程序将停止。这种行为在 Go 语言规范中关于程序执行的节中有描述(强调我自己的):

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


缺陷

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

多个 goroutine 示例

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

在计时器触发并且您向 goroutine 发出信号后,是时候杀死孩子并停止工作了,没有什么可以导致main方法阻塞并等待此操作完成,因此它返回。根据语言规范,程序退出。

调度器可能会在通道传输后触发,因此在main退出和其他 goroutines 唤醒接收来自ch. 然而,假设任何特定的行为交错是不安全的——而且,出于实际目的,在main退出之前不太可能进行任何有用的工作。该sleep子进程将被孤立; 在 Unix 系统上,操作系统通常会将进程重新作为进程的父init进程。

单协程示例

在这里,您遇到了相反的问题:main不返回,因此子进程不会被杀死。这种情况只有在子进程退出时(5分钟后)才能解决。发生这种情况是因为:

  • 该呼叫cmd.WaitRun方法是一个阻塞呼叫(文档)。该select语句被阻塞等待cmd.Wait返回错误值,因此无法从quit通道接收。
  • quit信道(声明为chmain)是一种无缓冲通道。无缓冲通道上的发送操作将阻塞,直到接收器准备好接收数据。从频道语言规范(再次强调我自己的):

    容量(以元素数为单位)设置通道中缓冲区的大小。如果容量为零或不存在,则通道没有缓冲,只有当发送方和接收方都准备好时通信才能成功

    正如Run在 中阻塞的那样cmd.Wait,没有准备好的接收器来接收通过方法中的ch <- struct{}{}语句在通道上传输的值mainmain阻塞等待传输此数据,这会阻止进程返回。

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

cmd.Wait 正在阻塞

要暴露 的阻塞性质cmd.Wait,请声明以下函数并使用它代替Wait调用。此函数是一个包装器,其行为与 相同cmd.Wait,但有额外的副作用来打印 STDOUT 发生的情况。(游乐场链接):

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):
Run Code Online (Sandbox Code Playgroud)

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

在退出频道发送, ch, 块

main无法返回,因为用于传播退出请求的信号通道未缓冲且没有相应的侦听器。通过改变线路:

    ch := make(chan struct{})
Run Code Online (Sandbox Code Playgroud)

    ch := make(chan struct{}, 1)
Run Code Online (Sandbox Code Playgroud)

通道中的发送main将继续(到通道的缓冲区)并main退出——与多个 goroutine 示例的行为相同。然而,这个实现仍然有问题:在main返回之前不会从通道的缓冲区中读取值来实际开始停止子进程,因此子进程仍然是孤立的。


固定版

我为您制作了一个固定版本,代码如下。还有一些文体改进可以将您的示例转换为更惯用的 go:

  • 不需要通过通道间接发出停止时间的信号。相反,我们可以通过将上下文和取消函数的声明提升到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()
}
Run Code Online (Sandbox Code Playgroud)

游乐场链接