Changjun Ji

设计上确实希望退出时清理IP。这里如果实际没有，那就可能是有bug。 是否可以帮忙调试下呢？ 1. 首先看看退出时，被测程序是否打印了这行log: https://github.com/qiniu/goc/blob/master/pkg/cover/instrument.go#L299 2. 同时看看goc server这一侧，是否接收到remove的情况，代码实现在这里: https://github.com/qiniu/goc/blob/master/pkg/cover/instrument.go#L262 信息越足，越方便我们定位问题。谢谢~ @susanaochaonan

> @CarlJi 程序自己退出（无论正常或异常）不会有 signal。 > > 使用 os/signal 也有缺点，用户程序原有的 signal 可能会比注入的 signal 先执行退出，导致 deregister 失败。 > > 根本原因是 Go 里面没有提供 atexit 行为，见[讨论](https://groups.google.com/g/golang-nuts/c/qBQ0bK2zvQA)，所以没有一种万全的方法来做全局的 "catch"。并发情况下一种全局的退出兜底方案是不存在的。 部分场景有效也是好的。我们能明确目前方案的局限就好。

> 当goc服务停止重启后，如果有服务在goc停止时间内停止了，将会出现list有无效ip的问题 用的方式是在profile --force指令里判断是否清理，再加了一个定时任务的方式 发现在建立连接时好像没有定义超时时间 "建立连接时好像没有定义超时时间" 这里是否可以具体下？ @zhanglianxin123

> 还有 > > https://github.com/qiniu/goc/blob/ee63433ca4e361e5e1f209e62757c5f402659edf/pkg/build/inject.go#L267-L283 > > > 这里如果mode是set 可以只有0 -> 1的时候才发通知到通道 > 可以提供个选项？选项的主旨是仅当第一次触发才通知 当然适用于其他mode 比如count > 0就不通知了 只有0 -> 1会通知 > 场景: 比如mode是set时 通过watch想实际变化后生成总覆盖率 但是现在的watch只要触发倒桩代码就会通知 假如有很多相同代码版本的service就会merge消耗cpu很多 这边暂时用了rate来限制 > >...

另外，你这边怎么会要用到这个watch的能力呢？具体场景是怎样的呢？

@gujing032 是否可以再具体描述下你这里的"增量"？ 我理解的增量场景大概率是 - 作为研发，我提了一个PR/MR, 我只关心我这个PR的里面的代码覆盖率变化情况。而这个场景其实有些考量: 1. 代码放在哪里？github or gitlab？ 2. 基准覆盖率结果如何获得？ 所以这是个强环境相关的场景。目前goc落地了在Github里基于Prow的增量覆盖率场景，如果大家也使用Prow，可以尝试下: https://github.com/qiniu/goc/blob/master/cmd/diff.go#L51

No further questions, closing it now.

> in my view, the `increment`/`change`/`delta` is not for `previous coverage` but `code`, which means we only aim at how many new codes we have covered in a new branch....

> enricofoltran/simple-go-server/main.go:30.13,48.33 13 1 > > 统计出来的这几个数字分别代表什么意思呢？ 参见Go源码: https://github.com/golang/go/blob/master/src/cmd/cover/profile.go#L23 这是go语言定义覆盖率结果一种数据结构，基本意思代表: 文件名,起始行.起始列,结束行.结束列 这个坐标内有多少行语句 覆盖率了多少行

这里的"节点" 是指机器吗？ 如果是的话，那天生就支持啊。 和`go build`一样，`goc build`输出的也是二进制，二进制理论上是可以同架构系统下的任何地方执行的。当然在启动时，这个二进制需要与`goc server` 通信，所以只要保持这个通道畅通就可以了。 @sz891016