go - 通过上下文取消进入异步/等待模式

Question

在我的应用程序中，我需要具有上下文取消支持的异步/等待模式。实际上，我有一个类似的功能:

func longRunningTask() <-chan int32 {
    r := make(chan int32)

    go func() {
        defer close(r)
        
        // Simulate a workload.
        time.Sleep(time.Second * 3)
        r <- rand.Int31n(100)
    }()

    return r
}

但是，它将不支持上下文取消。为了解决此问题，我可以添加一个参数并修改函数以在select语句中等待ctx.Done() channel 信号，如果上下文被取消，则中止操作。
如果以这种方式完成，则该函数将无法运行两次或两次以上(因为将共享上下文指针)，因为上下文取消 channel 仅接收到一个信号:

ctx := ...
go func() { r := <-longRunningTask(ctx) } // Done() works
go func() { r := <-longRunningTask(ctx) } // ?
// cancel() ...

这是我对“完成”的了解:

   // go/context.go

   357  func (c *cancelCtx) Done() <-chan struct{} {
   358      c.mu.Lock()
   359      if c.done == nil {
   360          c.done = make(chan struct{})
   361      }
   362      d := c.done
   363      c.mu.Unlock()
   364      return d
   365  } // Done() returns the same channel for all callers, and cancellation signal is sent once only

go源代码是否表示context确实不支持调用其他“长时间运行”功能的“链式取消”功能的中止？

有哪些写异步函数的选项，这些函数将在.Done()使用的无限递归中支持上下文取消？

Answer 1

1. Does the go source mean context does not really support abortion of a function that calls other "long-running" functions, "a chained cancellation"?

否。一个任务可以调用其他长期运行的任务，并在调用链中传递上下文。这是标准做法。而且，如果取消了上下文，则嵌套调用将出错并在调用堆栈中冒泡取消错误

2. What are options to write asynchronious functions that will support context cancellation in an unlimited recursion of .Done() usage?

递归与几个使用上下文的嵌套调用没有什么不同。如果递归调用采用上下文输入参数并返回错误(即检查)，则递归调用链将使取消事件冒泡，就像一组非递归嵌套调用一样。

首先，让我们更新包装器功能以支持context.Context:

func longRunningTask(ctx context.Context) <-chan int32 {
    r := make(chan int32)

    go func() {
        defer close(r)
        
        // workload
        i, err := someWork(ctx)
        if err != nil {
            return
        }
        r <- i
    }()

    return r
}

然后someWork-使用 sleep 工作负载将如下所示:

func someWork(ctx context.Context) (int32, error) {

    tC := time.After(3*time.Second) // fake workload

    // we can check this "workload" *AND* the context at the same time
    select {
    case <-tC:
        return rand.Int31n(100), nil
    case <-ctx.Done():
        return 0, ctx.Err()
    }
}

这里要注意的重要一点是，我们可以通过改变伪造的“工作量”(time.Sleep)，使其成为一个 channel -并通过select语句来观察它和我们的上下文。大多数工作量当然不是那么琐碎...
幸运的是，Go标准库完全支持context.Context。因此，如果您的工作负载包含许多可能长时间运行的SQL查询，则可以将每个查询传递给上下文。与HTTP请求或gRPC调用相同。如果您的工作负载包含这些调用中的任何一个，则在取消上下文时，传入父上下文将导致这些潜在阻塞的调用中的任何一个返回错误，因此您的工作负载将返回一个取消错误，让调用者知道发生了
如果您的工作量不完全适合此模型，例如计算大的Mandelbrot集图像。由于轮询选择不是免费的，因此在每个像素之后检查上下文取消是否会对性能产生负面影响:

select {
case <-ctx.Done(): // polling select when `default` is included
    return ctx.Err()
default:
}

在这种情况下，可以应用调整，如果说像素以10,000/s的速率计算-每10,000个像素轮询一次上下文，将确保任务在取消点后不迟于1秒返回。