Browsed by
分类:Lua

从Python到Lua

从Python到Lua

在码农世界里,有几个迷之争论:Vim/Emacs与IDE之争、Tab与Space之争、Windows与Linux(也包括macOS等)之争,诸如此类。任何一个争论都是莫名激烈、动不动就友尽,如果你恨一个人,就把他拖进这些争论吧。

其中最可能流血、最板砖横飞的争论,无疑是语言之争(当然,“PHP是世界上最好的语言”这是毋庸置疑的)。使用某个语言或者不使用某个语言,都可能轻易引发激烈的争吵,需要面对巨大的宗教、舆论压力,因此切换语言对码农来说,几乎就是死生之大事。

最近做了一件让人紧张、脸红、流汗的事:重新改写miniSIPServer产品的业务引擎部分,从Python语言切换到Lua语言。作为熟悉(非精通)Python多年的开发人员,离开自己的舒适区去面对新的挑战,去填新的坑,内心还是蛮纠结的。这个切换工作花费了几个月的时间,排除拖延症导致的时间浪费,如此耗时也是近几年罕见,通常一个复杂点的特性也就几个星期工作量而已。在产品博客上,已经简要描述了这次切换的原因,本文从开发人员视角再补充一些细节。

先泛泛了解一些Python和Lua的共性部分:都是脚本类、解释型语言;都是比较简单、干脆的语法;通常都会应用于粘合性场景。常见的不同之处主要在于:Lua更精干、小巧、速度更快,而Python是通用性、全栈型语言,有更广泛的库支持。Python即可适合开发独立的应用程序、也适合作为胶水语言嵌入到应用中,而Lua基本功能集很小,通常只适合作为辅助型语言使用,不太适合作为独立应用的开发语言使用。

从上面这些简要描述来看,Python语言的应用领域要比Lua广泛得多。实际上简单搜索一下可以发现,Lua仅仅在网络、游戏等领域才有一些应用范例。

离开具体应用场景来谈论语言的优劣就是耍流氓,在考虑、考察了很久以后,最终还是重新选择了Lua,这个决定过程是逐步养成的。

我们自己在设计、开发产品时,总是会狂热地追求简单、精致、高效等特性,从产品名称也可以看出我们对『小巧』的迷恋。将Python及支持库打包进安装包,有数MB之大,而Lua仅仅200KB而已,完成整体打包后,体积能缩小1/3,用户下载我们应用程序的时间相应也能减少1/3!这点从一开始就很吸引我们。

然而最初我们选择的是Python,因为Python的库实在太方便了!例如其中的smtp库、xml库等,在我们产品初期的确帮了大忙。而随着我们自己逐步在MSS的核心自行开发了这些基础库,重新审视后发现:Python的库对我们的产品不再是必须的了。这也就是我们重新思考的一个触发点。

如果说Python是屠龙刀,那Lua就是铅笔刀。如果仅仅是削铅笔,那显然铅笔刀比屠龙刀更合适。对于我们而言,应用脚本语言更多的是考虑对核心功能的封装,以及基于此编写业务逻辑脚本,以脚本语言的动态性适配客户需求的多样性。因此在核心功能完备的情况下,脚本语言越轻巧越好,越简单越好,Lua太适合这种场景了。

Python另外一个让人比较诟病的地方就是GIL。由于GIL的存在,Python无法实现真正的多线程。如果用一个Python实例来满足多种业务的需求,一旦其中一个业务出现问题,整个Python虚拟机可能会锁死,导致整个系统崩溃。如果采用多个Python实例,Python的VM实在太重了,对系统的设计、实现、工作负荷都会造成很大的困扰。

而在这点恰恰发挥出Lua的优势。Lua的VM非常小巧,以至于可以毫不犹豫地启动多个VM来实现业务。实际上,我们最终实现为『一个业务启动一个Lua的VM』。具体设计、实现时不用再考虑资源锁死的问题,而且Lua提供的coroutine也很棒,很多场合下可以轻松满足高性能的要求。启动多个Lua的VM带来的最大好处就是:系统的稳定性有了进一步的提高。事实上相当于每个业务都处于沙盒之中,一旦某个业务出现异常,其他业务可以完全不受影响,即使是对已出问题的业务实例,将沙盒(VM)抹掉即可。单纯这一个特点就足以让我们决定放弃Python,改用Lua了。

而Lua带来的第二个好处是『热更新』特性。在运营级、大型企业级软件系统中,『热更新』是非常重要的特性,可以确保整个系统尽可能地稳定运行。而由于每个业务都由独立的VM运行,因此我们可以做到动态修改业务脚本。实际上,我们在开发新业务引擎时,常常在保持MSS运行的情况下,修改脚本测试各种业务逻辑,效果良好。

Lua比Python简单很多,不做特殊优化,Lua的速度比Python要高出很多。我们在开发测试过程中发现,采用Lua脚本对系统的性能影响不大,比Python要节省资源。MSS作为一个高性能SIP服务器,核心采用C、C++实现,而某些处理过程也有客户化、定制化的需求,更关键的是也存在『热更新』的需求,因此我们甚至希望在考察Lua业务引擎效果的基础上,考虑替换MSS呼叫核心部分的处理逻辑,用Lua实现部分呼叫引擎。

因为简单,所以我们可以比较随意地直接修改Lua的代码,以便满足我们应用场景的一些特殊需求。而面对Python,我们可不敢这么做。

当然Lua也有明显的缺点,『简单』在某种程度上是『简陋』的同义词。很多情况下需要扩展一些功能给Lua使用,另外就是Lua也存在不少的坑,即使是Python和C/C++老手也需要小心翼翼。

最后,老话说得好:“结合应用谈语言”。没有完美的语言,只有适合你应用的语言。当你不知道该怎么选择时,选择Python、Java这类通用型语言基本无风险,正如我们在项目早期作出的选择一样,在当时都是非常正确的。只是我们要与时俱进而已。

Lua小坑之整数

Lua小坑之整数

在最近的一次开发中,需要将两个整数做除法,例如以下简单语句:

c=a/b

由于a和b都是整数,因此我又想当然地认为c也是整数,而实际上Lua将c转换成浮点数,导致后续逻辑判断和处理都出错了。这又是Lua让人意外的一个地方,我很困惑设计者为什么要这么设计。在Lua 5.3的reference manual文档中,对此有明确说明:

Exponentiation and float division always convert integer operands to floats.

据说5.3版本之前,Lua甚至都不支持整数,只有浮点数。而我们的程序通常只有两种类型:整数和字符串,因此重新将计算结果转换回整数是个急需解决的问题。在翻看manual文档时,看到math.tointeger接口,试了一下,结果极为悲催,返回了nil值!这是搞个毛线啊?

幸运地是lua对C很友好,因此只好手工打造一个接口给Lua程序用:

static int bluaToInt(lua_State *L)
{
 assert(NULLP!=L);
 int intVal = 0;
 int type = lua_type(L,1);
 switch( type )
 {
 case LUA_TNUMFLT: 
 intVal = (int)luaL_checknumber(L,1);
 break;
 
 case LUA_TNUMINT:
 intVal=(int)luaL_checkinteger(L, 1);
 break;

 case LUA_TSTRING:
 intVal = BclStrToInt(luaL_checkstring(L,1));
 break;
 
 default:
 assert(0);
 break;
 }

 lua_pushinteger(L, intVal);
 return 1;
}

将上述函数注册到Lua中,定义为“ToInt”,然后在脚本中使用即可。由此上述示例代码变为:

c=ToInt(a/b)

这样就能确保c为整数类型。

C向Lua函数传递table参数

C向Lua函数传递table参数

有时需要向函数传递相对比较复杂的数据,定义多个形参显得很难看,C语言函数中通常传递一个数据结构,而对于lua最直接的莫过于传递一个table数据。C调用lua函数时,也可以通过构造table数据传递给lua函数。

基本步骤比较简单,大致是(1)获取lua函数(2)在栈中构造一个table(3)向table中压入相应的数据(key-value)(4)执行lua函数。

以下伪码详细描述了这个过程:

......
lua_getglobal(L, "demoFunc"); // 获取Lua函数名

lua_newtable(L); // 创建一个table
lua_pushstring(L, "intVal");  //key为intVal
lua_pushinteger(L,1234);      //值为1234
lua_settable(L, -3);          //写入table
lua_pushstring(L, "strVal");  //key为strVal
lua_pushstring(L, "yxh");     //值为yxh
lua_settable(L, -3);          //写入table

lua_pcall(L,1,0,0); // 调用demoFunc函数
......
Lua路径

Lua路径

在学习的路上踩坑不止,今天遇到这个坑是关于“路径”的。

在windows版本中,lua默认的路径包括当前路径,以及当前路径下的lua子目录。因此测试时,理所当然将所有lua文件都放在当前目录的lua子目录下。

切换到linux系统(debian 8),发现lua默认没有当前lua子目录。当然,可以修改lua文件,在require语句中明确增加lua来规避,例如以下语句:

local fsm = require "lua.services.fsm"

对此不同系统下的表现颇感迷惑。检查了一下Lua的代码,发现的确有差异。对于LUA_PATH_DEFAULT宏的定义,windows系统默认包含当前目录以及lua子目录,而linux系统居然默认指向“/usr/local”目录(以及该目录下的各类子目录),当然也包含了当前目录,然而却没有包含当前lua子目录。

统一两个系统的表现也很简单,无非是修改linux系统环境中的LUA_PATH_DEFAULT定义,增加当前lua子目录,例如:

"./lua/?.lua;" "./lua/?/init.lua;" \
 "./?.lua;" "./?/init.lua"
luaL_loadfile的坑

luaL_loadfile的坑

在众多demo中,都是使用这个函数加载lua文件,然后由C程序调用lua提供的function或者value。但是调用该函数后,如果直接使用lua_getglobal去获取对应的lua函数,只会获取到空值。

luaL_loadfile实际调用了lua_load函数来加载lua文件。需要注意的是:lua_load仅加载lua代码块,但是并不运行。如果成功,会加载一个编译好的代码块作为一个匿名函数放置在栈顶。只有首先执行这个代码块,lua的vm才能最终知道各函数、变量等信息。

调用luaL_loadfile之后,应当接着调用lua_pcall执行匿名代码块,后续C代码才能有效调用Lua的函数。这样显然是比较繁琐的,lua中又提供了luaL_dofile宏来封装这两步过程:(1)加载;(2)执行。

因此,一般情况下,应该使用luaL_dofile来替代luaL_loadfile。

鸡肋的面向对象

鸡肋的面向对象

最近在研究Lua语言,主要参考Lua语言文档。简单地做了一些练习,感觉有点新鲜,也有点不适。

其中关于“面向对象”的章节实在太诡异,太拧巴了。单是那莫名其妙的冒号“:“就让人抓狂,更不用说对table的各种元操作。太夸张了,这是认真的么?作为有C++、python等语言背景的开发人员,我不得不说:这简直是为了面向对象而面向对象,无论是定义方式还是实现方式都太烂了!table固然让人击节赞叹,扭曲她去实现所谓的面向对象,有种美女变野兽的残暴感。

如果使用Lua语言,根本没有必要在意面向对象。Lua语法如此魔性,使用者应该抛弃面向对象的思维方式,而直接走函数式编程路子,堪称完美!

Lua的真

Lua的真

居然将0和空字符串也视为“真”!学了这么多种语言,第一次遇到将0判真的情况。

而且数组下标默认从1开始!好吧,印象中Fortran似乎也是这么处理。

大家的精力真是无限,毫无意义地浪费在这些繁琐的细节上。