use context with cancel

[DuodenumL]

之前很多地方用的context.TODO() / Background()，在一些注意不到的地方（比如mutex里）可能会产生goroutine阻塞。

主要在rpc的入口处做了处理，保证每个rpc api里用的都是带cancel的context。实际上还有一些地方绕过了rpc而直接调用了cluster / calcium，并且没有使用WithTimeout / WithCancel，修补了一下。

[jschwinger233]

这批改动一个容易犯的错误是对孤儿 goroutine 造成影响.

孤儿 goroutine 对应孤儿进程的的概念, 就是创建者不等 goroutine 运行完自己就先退出了, 像 create 流程最后的 remap 就是孤儿 goroutine.

比如下面这种代码结构, 如果不加分辨地把 context.TODO 改为 CancelContext 并且 defer cancel() 就有问题:

func a() {
    ctx := context.TODO() // 这里改成 ctx, cancel := context.WithCancel(); defer canel() 就有问题
    b(ctx)
}

func b(ctx context.Context) {
    go func() {
        runLongTime(ctx)
    }()
}

[DuodenumL]

这批改动一个容易犯的错误是对孤儿 goroutine 造成影响.

孤儿 goroutine 对应孤儿进程的的概念, 就是创建者不等 goroutine 运行完自己就先退出了, 像 create 流程最后的 remap 就是孤儿 goroutine.

比如下面这种代码结构, 如果不加分辨地把 context.TODO 改为 CancelContext 并且 defer cancel() 就有问题:

func a() {
    ctx := context.TODO() // 这里改成 ctx, cancel := context.WithCancel(); defer canel() 就有问题
    b(ctx)
}

func b(ctx context.Context) {
    go func() {
        runLongTime(ctx)
    }()
}

是的，我也相应地检查了这种情况是否存在。对于remap来说，已有的做法是用utils.InheritTracingInfo(ctx, context.TODO())来复制之前的tracing info和peer信息，但是不直接继承自原本的context，也就不会因为ctx cancel导致remap失败。这个InheritTracingInfo在很多地方都有应用，基本上都是出于“复制但不继承”的目的。