Open synckey opened 2 months ago
你说的是对的,提一个PR更好
是的,我们这边遇到过这类问题——NTP误差或人为操作等原因导致的时钟跳变会导致触发时机提前或者延后。
对于进程内的计时,用单调时钟更合理,避免时钟跳变的影响。
之前尝试改了一下定时器的实现,运行是没有问题的。目前考虑:框架内部计时统一使用单调时钟。对于已经对外的墙上时钟接口,内部转成单调时钟。另外提供对应的单调时钟接口。但是pthread锁相关接口用的是墙上时间。
@wwbmmm 有什么建议吗?
是的,我们这边遇到过这类问题——NTP误差或人为操作等原因导致的时钟跳变会导致触发时机提前或者延后。
对于进程内的计时,用单调时钟更合理,避免时钟跳变的影响。
之前尝试改了一下定时器的实现,运行是没有问题的。目前考虑:框架内部计时统一使用单调时钟。对于已经对外的墙上时钟接口,内部转成单调时钟。另外提供对应的单调时钟接口。但是pthread锁相关接口用的是墙上时间。
@wwbmmm 有什么建议吗?
我看pthread提供了pthread_condattr_setclock来设置时钟类型,我们是否也可以提供相应的选项?
支持设置时钟类型,这样更灵活,但是TimerThread得同时支持两种时钟模式,复杂度可能会变大。
支持设置时钟类型,这样更灵活,但是TimerThread得同时支持两种时钟模式,复杂度可能会变大。
太复杂就没必要了,看实际需求吧,RPC的需求是不是用单调时钟都可以满足?
是的,RPC用单调时钟就可以满足超时的需求了。
Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)
brpc 中的很多超时和唤醒逻辑都使用了墙上时钟,在系统时钟跳变时会产生很多问题。
比如以下代码:
请求超时时间:https://github.com/apache/brpc/blob/master/src/brpc/channel.cpp#L552
条件变量等待时间:https://github.com/apache/brpc/blob/master/src/bthread/condition_variable.h#L75
sleep时间:https://github.com/apache/brpc/blob/master/src/bthread/task_group.cpp#L775
Describe the solution you'd like (描述你期望的解决方法)
切换成 monotonic clock ?
Describe alternatives you've considered (描述你想到的折衷方案) No