我想按需取消正在运行的命令,为此,我正在尝试exec.CommandContext,目前正在尝试这样做:
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退出功能/杀死正在运行的命令。
cancel()
time.Sleep(time.Second)
main
关于如何wait在退出不使用sleep?之前确保命令已被杀死的任何想法?cancel()成功杀死命令后,可以在通道中使用它吗?
wait
sleep
在尝试使用单个goroutine的过程中,我尝试了以下操作:https : //play.golang.org/p/r7IuEtSM-gL,但cmd.Wait()似乎一直在阻塞,select并且无法调用cancel()
cmd.Wait()
select
在Go中,如果到达main方法的结尾(在main包中),程序将停止。Go语言规范中有关程序执行的部分(强调我自己)中描述了此行为:
程序执行首先初始化main程序包,然后调用函数main。当该函数调用返回时,程序退出。 它不等待其他(非主)goroutine完成。
我将考虑您的每个示例及其相关的控制流缺陷。您会在下面找到“转到游乐场”的链接,但由于sleep找不到可执行文件,因此这些示例中的代码将不会在限制性游乐场沙箱中执行。复制并粘贴到您自己的环境中进行测试。
case <-time.After(3 * time.Second): log.Println("closing via ctx") ch <- struct{}{}
计时器触发后,您向goroutine发出信号,是时候杀死孩子并停止工作了,没有什么main可以阻止该方法并等待该方法完成的,所以它返回。根据语言规范,程序退出。
调度程序可能会在频道传输后触发,因此在main退出与其他goroutine唤醒以从接收信号之间可能存在竞争ch。但是,假设行为有任何特定的交织是不安全的- 出于实际目的,在main退出前不太可能进行任何有用的工作。该sleep子进程将被孤立 ; 在Unix系统上,操作系统通常会将进程重新建立父init进程。
ch
init
在这里,您面临相反的问题:main不返回,因此子进程不会被杀死。仅在子进程退出时(5分钟后)才能解决这种情况。发生这种情况是因为:
cmd.Wait
Run
quit
容量(以元素数为单位)设置通道中缓冲区的大小。如果容量为零或不存在,则通道没有缓冲,并且 仅在发送方和接收方都准备就绪时通信才能成功 。
如中Run所阻止cmd.Wait,没有就绪的接收器可以接收方法中的ch <- struct{}{}语句在通道上传输的值main。main块等待传输此数据,从而防止进程返回。
ch <- struct{}{}
我们可以通过较小的代码调整来演示这两个问题。
要暴露的阻塞性质cmd.Wait,请声明以下函数并在Wait调用中使用它。此函数是一个包装程序,具有与相同的行为cmd.Wait,但是还有其他副作用,可以打印STDOUT发生的情况。(Playground链接):
Wait
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秒)来快速观察。
Waiting on command <pointer>
calling ctx cancel
Returning from waitOn <pointer>
main无法返回,因为用于传播退出请求的信号通道是未缓冲的,并且没有相应的侦听器。通过更改行:
ch := make(chan struct{})
至
ch := make(chan struct{}, 1)
通道上的发送main将继续(到达通道的缓冲区)并main退出- 与多goroutine示例相同的行为。但是,此实现仍然失败:将不会从通道的缓冲区读取该值,而实际上不会在main返回之前开始停止子进程,因此该子进程仍将被孤立。
我为您制作了一个固定版本,代码如下。还有一些样式上的改进,可以将您的示例转换为更惯用的语言:
我保留了单独的Run函数来演示以这种方式传递上下文,但是在许多情况下,可以将其逻辑嵌入到main方法中,并生成一个goroutine来执行cmd.Wait阻塞调用。
case
sync.WaitGroup
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() }
(游乐场链接)