程序员的执念

昨天在看一个吉里吉里(krkr)Timer问题,开启Timer后,游戏会随机崩溃,报错说Timer已经被删除。

题外话,我个人是很讨厌Timer这种东西的。我见过很多糟糕的Timer设计,而且它容易被滥用。使用者会产生一种“我在做并行逻辑”的错觉,而且大部分设计者在设计有关Timer的逻辑时,并没有完全想明白。随口设计出诸如“延迟x秒发生这个,再延迟y秒发生那个”,当这些逻辑交织在一起的时候,无论是设计还是实现都会非常困难,edge case很多,最终导致产生不可预期的结果。

但Timer本身不复杂,对于krkr这样针对电子小说的游戏引擎更是如此。我随口说了句总不至于多线程吧?毕竟krkr内部的解释器是单线程的,所以Timer触发的逻辑肯定得在主线程里执行。但这样一来解释不了Bug的成因,为何会出现删除Timer后OnTimer函数仍然被调用,并且在OnTimer里面操作Timer的时候又说Timer已经被删除?我脑补了两个原因:

1、删除Timer不会终止它的OnTimer函数,这种设计是引擎缺陷。

2、OnTimer触发后就无法被取消了,这种设计也是有问题的。

脑补当然没用,看代码就好了。于是我翻出krkr的源码,找到Timer的实现,还真是多线程……然后就脑补了20种多线程的常见问题。等读完源码,发现逻辑虽然饶了几圈,但bug是没有的,大致上是这样的过程:

krkr首先启用一个单独的线程来处理Timer触发的逻辑,它通过::Sleep来控制Timer的等待(很不精确,但省CPU)。被触发的Timer通过PostMessage传递给隐藏Win32 HWND,然后在独立的UtilWndProc执行逻辑。因为UtilWndProc是由主线程创建的WindowProc callback,所以和解释器处在同一个线程。在这个消息处理函数中,Timer逻辑被丢给了自带的Event模块,Event模块执行实际的OnTimer。krkr保证了如果一个Timer被删除,它在Event中注册的所有OnTimer事件同时也会被删除。已经在等待队列的Timer,检查到自己被删了就直接return,什么都不会发生。

我个人觉得这个Timer实现的太复杂了,可能20多年前CPU宝贵,krkr没有一个持续tick的函数,只能通过多线程来实现吧。而windows里这样传递消息也是krkr固有的模式,其他人提到过:http://bbs.niratea.org/test/read.cgi/krkr/1323994344/389

总之我假设的两个问题都是不存在的。这样一来就是上层逻辑的问题了,于是仔细看了看,发现了真正的原因(WTF,为什么一开始不看?):

1、删除一个krkr对象,并不会自动把对象引用置为void。这个操作非常c++,但对于自带gc的脚本引擎来说还是挺猎奇的。这个错误的假设造成了一些逻辑问题。

2、Timer被多次创建,且保存在parent的成员变量上。这样新创建的Timer会导致旧的Timer引用丢失,而gc并不会第一时间删除这些timer。一旦新的Timer被删除,旧的OnTimer函数被触发的时候,旧的OnTimer函数里通过成员变量访问的“自身”已经是新的Timer,所以会出现问题。

修复很简单,每次创建新Timer前记得删除旧的即可。

这个问题其实可以通过引擎的设计来避免,毕竟用户可能会犯错。OnTimer如果能传入自己,用户就没有必要通过额外的方式保存Timer的引用,这样OnTimer可以保证操作的timer对象肯定是有效的。用户即使重复创建Timer,造成的结果也无非是Timer被重复触发,而不是抛出异常。另外带gc的脚本引擎提供删除功能真的好么?20年前内存大概也非常宝贵吧。

当然,正确的使用Timer才是解决问题的根本。不过我之前就说过,Timer是个容易被误用的模块。尤其是游戏,大部分基于Timer的设计逻辑都是经不起推敲的(个人看法),能少用就少用吧。

Leave a Reply

Your email address will not be published. Required fields are marked *