缩小lua出错影响范围

如果游戏主逻辑放在lua中，c只是作为网络模块，游戏中lua需要暴露给c的接口很少：

1.响应RPC

2.timer

3.开启服务器

4.关闭服务器

如果脚本出错， 由于是通过lua_pcall调用脚本的，一次调用为一个崩溃域，不会影响到另一次调用。

134，一般一次只会调用到一个函数，这个函数可能会调用到其他很多函数，但是此函数是作为一个模块中完整的逻辑功能的实现。

但是timer就不同了，如果timer的所有定时循环、timeout、函数信息都放在lua脚本中。

设为30秒检查一次，就是每30秒c调用lua中一个函数比如onTimer。然后所有然后在其中检查是否有到时间的函数，可能到时间的有好几个函数。

其中一个函数出错，这次pcall就崩溃了，其后一起到时间的函数就都没调用到了。

所以必须改变这种timer实现方式，其中要点是一次lua_pcall只调用一个到时间的函数，而不是多个。

1.

timer的所有定时循环、timeout、函数信息都放在lua脚本中。

设为30秒检查一次，就是每30秒c调用lua中一个函数比如onTimer。然后所有然后在其中检查是否有到时间的函数，可能到时间的有好几个函数。

就是现有的方式，弊端上面讲到了。

但是如果lua有try catch，就可以对每个到时的函数使用了，可惜还没有。

2.

timer的所有定时循环、timeout、函数信息都放在c中。

这样会增加lua需要暴露给c的接口，很麻烦，每个需要添加为定时调用的函数都要暴露。

3.

timer的所有定时循环、timeout、函数ID放在C。

ID对应的函数信息放lua。

这种方式没有弊端，可行。

4.

timer的所有定时循环、timeout、函数信息都放在lua脚本中。

实现方式类似1，一次可能查到有好几个到时间的函数，但是onTimer中只调用其中一个。返回0给C表示此次onTimer没有多余需要调用的函数了，返回1给C表示此次还有到时间的函数，需要C马上再调用此onTimer。

没有弊端，可行。

总结：一次lua_pcall只干一件事。