0

我一直在阅读一些关于使用 golang 的 context 包的文章。我最近在博客中看到了以下文章：http: //p.agnihotry.com/post/understanding_the_context_package_in_golang/

该文章对 go 中的上下文取消功能进行了以下说明：

“如果你愿意，你可以传递取消函数，但是，强烈不建议这样做。这可能导致取消的调用者没有意识到取消上下文可能会对下游产生什么影响。可能还有其他派生的上下文这可能会导致程序以意想不到的方式运行。简而言之，永远不要绕过取消函数。

但是，如果我希望激活父 context.Done() 通道，将取消函数作为参数传递似乎是唯一的选择（请参见下面的代码片段）。例如，下面代码片段中的代码 Done 通道仅在执行 function2 时才被激活。

package main

import (
    "context"
    "fmt"
    "time"
)

func function1(ctx context.Context) {
    _, cancelFunction := context.WithCancel(ctx)
    fmt.Println("cancel called from function1")
    cancelFunction()
}

func function2(ctx context.Context, cancelFunction context.CancelFunc) {
    fmt.Println("cancel called from function2")
    cancelFunction()
}

func main() {
    //Make a background context
    ctx := context.Background()
    //Derive a context with cancel
    ctxWithCancel, cancelFunction := context.WithCancel(ctx)

    go function1(ctxWithCancel)
    time.Sleep(5 * time.Second)

    go function2(ctxWithCancel, cancelFunction)

    time.Sleep(5 * time.Second)

    // Done signal is only received when function2 is called
    <-ctxWithCancel.Done()
    fmt.Println("Done")
}

那么，传递这个取消函数真的是个问题吗？是否有与使用 context 包及其取消功能相关的最佳实践？

4

1 回答 1

1

在您的具体示例中，代码量足够小，理解它是如何工作的可能没有问题。当您更换function1并function2使用更复杂的东西时，问题就开始了。您链接到的文章给出了为什么传递取消上下文可以做一些难以推理的事情的具体原因，但更一般的原则是您应该尝试将协调工作（取消，旋转 goroutines）与底层工作分开，以尽可能地完成（无论做什么function1，function2正在做什么）。这只是有助于更容易独立地推理代码的子部分，并有助于使测试更容易。“ do <something>”比“ do <something> function2”更容易理解function2function1”。

无需将取消函数传递给function2，您只需在生成的 gooutune 中调用它即可运行function2：

func main() {
  //...
  go func() {
    function2(ctxWithCancel)
    cancelFunction()
  }()
  //...
}

这是侄女，因为确定何时取消的协调工作全部包含在调用函数中，而不是分散在多个函数中。

如果你想function2有条件地取消上下文，让它显式返回某种值，指示是否发生了一些可取消的条件：

func function2(ctx context.Context) bool {
  //...
  if workShouldBecanceled() {
    return true
  }
  //...
  return false
}

func main() {
  //...
  go func() {
    if function2(ctxWithCancel) {
      cancelFunction()
    }
  }()
  //...
}

这里我使用了一个布尔值，但通常这种模式与errors 一起使用 - 如果function2返回一个非 nil error，则取消其余的工作。

根据你在做什么，类似的东西errgroup.WithContext可能对你有用。这可以协调多个并发操作，所有这些操作都可能失败，并在第一个操作失败后立即取消其他操作。

我尝试在上下文取消中遵循的另一种最佳实践：始终确保取消函数在某个时候被调用。在docs中，两次调用取消函数是安全的，所以我经常会做这样的事情：

func main() {
  ctx, cancel := context.WithCancel(context.Background())
  defer cancel()
  //...
  if shouldCancel() {
    cancel()
  }
  //...
}

编辑以回应评论：

如果您有多个长时间运行的操作（例如，服务器、连接等），并且您希望在第一个操作停止后立即关闭所有操作，那么上下文取消是一种合理的方法。但是，我仍然建议您在单个函数中处理所有上下文交互。像这样的东西会起作用：

func operation1(ctx context.Context) {
   for {
     select {
     case <-ctx.Done():
       return
     default:
     }
     //...
   }
}

func operation2(ctx context.Context) {
  // Similar code to operatoin1()
}

func main() {
  ctx, cancel := context.WithCancel(context.Background())
  var wg sync.WaitGroup
  wg.Add(2)
  go func() {
    defer wg.Done()
    defer cancel()
    operation1(ctx)
  }()
  go func() {
    defer wg.Done()
    defer cancel()
    operation2(ctx)
  }()
  wg.Wait()
}

一旦其中一个操作终止，另一个操作将被取消，但main仍等待两者完成。这两个操作都不需要担心管理这个问题。

于 2021-11-20T02:16:16.227 回答