Felix021

昨天黄老湿问了我个问题， [ -e ] 是true还是false？为什么？

==== 啦啦啦啦啦的分割线，猜猜吧 ====

这种坑题显然只能实践出真知：
果然坑了。

仔细想想，这个问题其实还是来源于实践的，比如一个很有可能会出现的写法是：
显然，在这个情况下，如果$somefile意外地是一个空串的话，bash实际上执行的就是 [ -e ] （这个可以很容易地验证），于是返回了 true。

简单过了一下源码(coreutils/src/test.c)，可以看到执行流是

也就是说对于只有一个参数的情况下，test只是简单地判断这个参数是否为空（无论是不是它支持的操作符），有两个参数的情况，才会去判断是否是合法操作符，再执行相应的检测。

然后才想起来，原来我还可以看manual啊，泪流满面。。。man test，果然看到这几行：
也就是说 test STRING 等于 test -n STRING ，检查非空串，于是 [ -e ] 就等于 test -n "-e"，自然就是true了。。。

对于上面提到的情况来说，解决办法是在引用变量的时候，记得加上双引号，这样test就会收到2个参数，其中第二个参数是空串，stat出错，于是就可以得到（可能原先）期望的结果了：
不过话说回来，bash脚本中引用不存在的变量这件事情本来就不应该发生，类似 rm -rf $some_path/ 这样的悲剧也不是没有发生过，但是bash又没有一个 explicit 模式，所以只能自己在使用之前检测了。

通常检测一个变量是否为空，用上面的 test -n "$VAR" 或者 test -z "$VAR" 即可(注意引号)，但是如果要检测某个变量是否根本不存在，BASH却没有内建方法，只能通过这种看起来很奇怪的方式（出自stack overflow)：

//本博客3月份真高产。。。

上一篇 说到，对于这样的一段代码：
Python解释器会为 a 和 b 各 创建一个 PyIntObject (通过修改PyInt_FromLong打印int的id可以看出来)，但是在实际的执行中，a和b却指向了同一个PyIntObject。也就是说，在执行之前，a和b已经被映射到了同一个PyIntObject。

前面说了，Python的解释执行是由以下调用链组成的：

由于没有编译原理的基础，只能从全局上看出这些代码都做了什么，但是却很难从细节上去追查。通过修改源码我尽可能了解了 PyParser 将Python源码转换成AST的运行机制（虽然还是没有看懂tokens->cst的转换），但是run_mod的细节实在是看不懂了。于是我在StackOverflow上面提了一个问题，@Bakuriu大牛给了个hint，说是PyCompiler在处理lambda的时候，使用 compiler_add_o() 来将lambda对应的函数的__doc__设置为 PyNone:
这里头PyNone是常量，而且又出现了 c->u->u_consts ，大有看头。

有了线索以后，突然一切都变得清晰了，简单加了些代码追，可以发现对于上面给出的代码， compiler_mod 是这样处理mod_ty *mod(也就是那棵AST)的：


简单解释下Assign操作的代码：
    1. 获得赋值目标的数量（比如a=b=1，就是2个）
    2. "VISIT"要赋的值
    3. 挨个ADDOP(c, DUP_TOP)是告诉编译器，增加一个OPCODE=DUP_TOP

DUP_TOP 是 Duplicates the reference on top of the stack 的简写，意思是取得上次计算的值（比如对于b，就是int(1)的reference，而对于a，就是b=1的返回值，也就是b的reference）加入stack_top，这样正好把多个赋值操作串起来。

不过我关注的主要是第二条，对应的代码就是:



这个compiler_add_o(struct compiler *c, PyObject *dict, PyObject *o)的作用是将一个变量o及其type组成的tuple(o, o->ob_type)塞入到dict中。但是并不是简单暴力地直接插入，它的源码大约是这样的：



这个代码乍看挺诡异的，因为还与后续编译成字节码的部分有所耦合，这里大致解释一下：

(1) 对于LOAD_CONSTS, 在compiler_visit_expr里面已将dict指定为c->u->u_consts，也就是专门用来存放常量的dict
(2) 所有常量都是用 (o, type(o)) 作为 key 存进去的，并返回顺序递增的编号v，表示o是第v个存进去的常量
(3) dict是个hash表，所以往dict里面塞东西时要计算key的hash
(4) tuple的hash值是将每个元素的hash值组合起来哈希(详见tuplehash函数)，类似于sdbmhash或者jshash
(5) int对象的哈希是针对int的值，int对象比较时仅比较它们的值

    尽管 a 和 b 对应的key (a, int)和(b, int)虽然不是同一个对象，但是它们的哈希值是一样的！并且！PyDict_GetItem()查找到某个slot去比较key的时候，递归地去比较key的每一个元素，而两个int的比较，“正好”是比较它们的值是否相等！

    所以，在遍历AST生成bytecode之前，两个相同的const只会在c->u->u_consts中出现1次。

    在compiler_mod函数的末尾有一个assemble(c, addNone)，它是将前面生成好的opcode等数据转换成最终的bytecode，其中一些代码逻辑是这样的



    也就是说，这里把保存所有常量的 c->u->u_consts 按照插入元素的顺序将所有塞进来的PyObject逐个插入到 consts 里，并最后赋值给PyCodeObject的PyListObject *co_consts。而在最最后的eval环节，LOAD_CONST这个opcode会将它的oparg(就是前面 compiler_addop_i 塞进去的值，也就是compiler_addop_o返回的值)作为索引，从co_consts里取出来，PUSH到栈顶（参见Python/ceval.c +1123行)，供下一个指令读取。

    于是int常量整个python的解释执行所经历的步骤都完整地串起来了。

    泪流满面，居然看懂了。

1. Python的除法

线上有一个简单的函数，运行一年多了，作用是把"分"表示的字符串转成"元"：
看起来也的确是没有什么问题，但是就这么简单的一点代码，它还是错了，原因是fen_to_yuan("-270")居然返回了"-3.30"！坑爹啊。简单测试一下，原来是这样：
所以只好蛋疼地修改成这样：

2. 线上有一个脚本，要得到上个月的月份，bash的实现就是

看起来也的确是没有什么问题，但是就这么简单的一点代码，它还是错了，原因是对于10月31号居然返回了10！坑爹啊。简单测试一下，原来是这样：
也就是说，先把月份减一，然后检查日期，超过当前月，再向上修正月份，再向上修正年份。

所以只好蛋疼地修改成这样：

#update: @whusnoopy补充说 向后查看1个月也会有这样的情况，总之记得用月来算是有坑的，千万注意。

3. crontab的小坑

crontab默认是不会读取.bashrc，需要自己去source一下.bashrc，并且不支持像bash一样用反引号来启动一个子命令（这个结论是错的，是因为%前面忘了加斜杠）。这个不展开细说了，有兴趣的试试吧。

看源码的时候经常要在某一类文件里面grep一些内容，用标准的find + grep写起来很辛苦：

$ find -name "*.c" -exec grep {} -Hne "hello world" \;

所以简单封装了下，保存成 ~/bin/xgrep 然后把 ~/bin 加入到 PATH 里去，以后就只需要

$ xgrep \*.c "hello world"    #注意这个 \*.c 里可以用的是*和?的通配符，不是正则


#后来才想起grep其实有个--exclude=PATTERN（可以去掉find），但是已经这么用了挺久，习惯了。。。

前天在 coolshell 里看到 并发框架Disruptor译文 以后 ，才感慨了CPU娘的傲娇，没一会儿就看到 Dutor 同学的 A False-Sharing Test ，发现差距好大（4线程4倍- ，16线程8倍+ ，我用dutor的代码实测16线程性能差距接近20倍），于是也写了段小代码来测试它。跟dutor同学不一样，我用的是 c 实现的，看起来可能没那么易读。



该机器使用的是4颗4核8线程的Xeon E7520@1.87GHz （16个物理核心32个逻辑核心），64GB RAM，/proc/cpuinfo里的cache_alignment是64

可以看出来，padding=56（也就是正好对齐到一个cache行）的时候效率最高，是没有填充时的2倍+的效率，虽然明显，但是显著地没有dutor的测试那么夸张。

把dutor的代码稍微改了下，s[ith].n = NLOOP，且pthread_create的时候传入的参数改成 (void *)&(s[ith].n)，然后hook程序改成
其运行效率提升显著，padding=56的时候能快10%左右，而padding=0的时候能快达7倍之巨，最终的性能差距大约可以降至 3 倍的差距。这说明dutor的测试方法并不是测试裸的性能差距，带来的了一定的误差。

由于现在多数CPU都已经有了共享的L2或者L3 Cache，Cache Line失效的问题得到了相当的改善，不过不同物理CPU上仍然需要注意这个问题。

然而有一点我不能理解，这个修改对两种情况的影响竟相差这么大，这里头又有什么玄机呢...... #UPDATE: 后根据dutor的测试，我去掉了 for 循环中用到的循环变量 i 之后，性能差距立即将至2倍左右，修改循环的方向或者将for改成while则无效，因此这很可能是分支预测失效带来的问题了。

早先翻python代码的时候是有注意到 intobject 里有缓存这档事，不过没细看。昨天有人在sf问起为什么有如下现象：
于是又翻开python的源码 python2.6.8/Objects/intobject.c ，可以看到这些代码(略做简化)：
而PyFloat_Object并没有（也不适合）实现这样的缓存，所以就可以解释上面的情况了。

更进一步，可以用257来验证一下，的确是超出了缓存的范围：

然后手贱做了另一个测试，蛋疼了：
也就是说如果让解释器一次执行的话，解释器又会再优化它，让a、b引用同一个对象。//注：这里对于float和str类型的常量效果是一样的。

为了搞清楚解释器到底是怎么实现这一点的，又把代码翻出来。之前翻的时候对解释器的执行流程已经有大致的了解了。make得到的python解释器是从 Module/python.c 里的 main() 函数开始的，调用链大约是这样：


从 PyRun_FileExFlags 开始，才能看到底层代码正式登场：

注：更详细的Python编译解释流程可参见这一系列： http://blog.csdn.net/atfield/article/category/256448

通过加入一些调试代码，可以窥探到内部的执行流。例如，在PyParser_AddToken中输出token的名称和类型编码；在PyParser_ParseFileFlagsEx()之后调用PyNode_ListTree()，可以看到生成的CST树（修改list1node()可以让它打印出更容易阅读的版本）；修改PyInt_FromLong()，让它在ival=257的时候输出创建的object的id（CPython实现中 id 其实就是指针的值）。加上一些代码以后，编译python，执行test.py可以看到如下输出：

从输出可以看到，解析源码生成CST的时候（输出的CST已经滤掉了非TERMINAL的node），每个token还保留着原始的字符串（例如0x101和257），而在CST到AST的转换过程中（PyAST_FromNode），解释器为每一个NUMBER都创建了一个PyIntObject。然而在程序运行的最终结果里可以看到，a is b的结果是True，也就是说，从AST转换到CFG并执行(run_mod)的过程中，解释器做了适量的优化，将 a 和 b 都指向了同一个 int 对象。

由于对CFG不熟，相应的代码还不太看得懂，所以暂时只能烂尾了，如果以后看懂了，再来补充。

续集：Python int缓存的那点事[续]

开篇先说一下，在它的manpage里面，有这么一句话：这是因为gethostbyname只能处理ipv4请求（经测试ipv6.google.com不能解析，ipv6.tsinghua.edu.cn只能解析出ipv4地址），因此推荐使用 getaddrinfo 来替代它。

忽略上述问题不管的话， gethostbyname 还是有点意思的。它的原型和用法大概可以这样：
用法特别简单吧，如果不是在提到这个函数的时候附带说明“它使用了内部分配的空间，因此不是线程安全的”，估计会大受欢迎的。
//注：由于windows版用了 thread local 的变量，所以在windows下它是线程安全的（只要不是同一个线程马上再调用覆盖它的话）。

相应的，像ctime、localtime之类的posix接口一样，它的线程安全版就是带了 _r 后缀的 gethostname_r ，虽然名字只复杂了一点点，但是接口可不只是复杂了一点点啊：其中的name是hostname（或者ip地址），ret应当指向一个分配好的struct hostent结构体（函数把内容填进去），buf应当指向一块分配好的空间（不小于buflen），result是一个struct hostent的二级指针（如果失败会存个NULL），h_errnop则指向某个int（失败则填对应的herr，这个奇葩函数的errno跟errno.h里面那个还不是一套）。

用起来真是相当地恶心，比如下面这个函数通过它来解析ip地址，跟前面的代码的复杂度完全不是一个量级的：

代码是写出来了，但是觉得不太对头，仔细看了一下 struct hostent 的定义，里头还有多个指针（h_name、h_aliases、h_addr_list）什么的：如果不释放的话，不会造成内存泄漏么？

于是去看了下gethostbyname和gethostbyname_r的源码，进入 eglibc-2.15 的源码， ctags -r 然后 vim -t gethostbyname ，竟然没有这个函数。然后翻了翻，看到有个 inet 目录，里面有个 gethstbynm.c 这样一个奇葩的文件，里面除了include一些头文件之外，只有一些简单的宏定义和一个奇怪的include：
打开一看 getXXbyYY.c 这个文件更奇葩了，根本就是用宏来实现C++中的模板功能啊。。。grep一下还发现，这个文件被18个其他文件include，也就是说，有18个函数（诸如gethostbyaddr, getnetbyaddr, 甚至getpwuid、getpwnam）都是用的这个模板。

凑合着看了一下，代码倒是不复杂（具体就不贴出来了），基本逻辑是这样的：
也就是说，代码流程基本上跟前面调用 gethostbyname_r 的代码一样，只是多了一个获取/释放锁的操作。根据里面的流程可以看出，代码里面不是使用静态的空间，而是动态malloc的（所以要获取锁，否则在libc内部崩溃，那不好）。由此，所谓的不是线程安全的，其实并不是函数本身，而是返回的数据。

但是，看懂了这个代码，并没有解决上面的问题啊。。。于是到 stackoverflow 上面去提了个问，很快就得到大牛的回答了：

也就是说，我完全忽略了塞给 gethostbyname_r 的 buf 这个参数：hostent 里面的指针指向的数据就存在 buf 里面，因此最后只要 free 掉它就够了。

由于有些域名可能绑定了好多个ip（比如google.com可能就绑了数十个），buf 的空间可能不够大，所以才需要一个realloc的机制。根据实测，buf的大小从512或者1024开始比较合适，普通的域名就不需要realloc了。

到此差不多该结束了，最后吐槽一句，这两个接口真奇葩啊。。。

这周写了个模块，让python可以跟后台的C服务通信了。

总体上来说给python写个模块还是比较容易的，比给php写模块要舒服多了，但是还是遇到一个问题：给php写模块的时候可以用MINIT完成初始化、MSHUTDOWN完成清理；给Python写模块，有对应的模块初始化函数，但是却没有对应的清理函数，实在是令人蛋疼。

需求其实很简单（应该也很普遍吧？），只是要在python退出之前执行一点代码，保证在初始化的时候分配的一些资源能够被释放；但是模块本身并没有提供这样的机制，只好想其他办法了。

最简单的是用C语言本身提供的 atexit ，不过这是在main()结束或者调用exit()时 - 也就是说，在整个C环境要结束了的情况下才会运行（但是在关闭所有打开的文件之前）。

虽然有效，但是由于它不是python提供的机制，多少让人有点不太放心，所以还是看看别人怎么用的吧。

Google搜了一下"python  module  destructor"，stackoverflow上说的是，可以用python的 atexit 模块。这是一个纯python模块，源码可以在 /usr/lib/pythonX.X/atexit.py 看到，其实就是通过 atexit.register() 注册退出函数，并将 atexit._run_exitfuncs() 函数绑定到 sys.exitfunc 。sys.exitfunc会在Py_Finalize()这个函数中被调用（call_sys_exitfunc()）。

在C模块里调用它，最简单的办法是在模块的初始化函数里加入类似这样一句（注意换行和缩进）：
这大致相当于在python脚本里用eval执行了一段代码（没有指定globals、locals和compile_flag）。也可以用如下几乎等价的纯C代码

由于错误处理、引用计数的代码占了一大半，所以代码这么长……

这种方法的好处是，它在python运行环境结束之前执行注册的函数，所以注册的函数仍然可以使用绝大部分python提供的功能（你甚至可以再import新的模块，但是最好别用thread...）。然而atexit有一个蛋疼的缺陷：尽管python在sys模块的doc里写的是“Assigning to sys.exitfunc is deprecated; use the atexit module instead.”，但是sys.exitfunc仍然是任意python脚本都可以修改的！所以通过atexit.register()注册的函数并不能100%保证被运行。

再回过头来看Py_Finalize()函数，这里其实是有很大槽点的：它有一个长达十一行的"sundry finalizers"段！
也就是说，它为许多内置的module逐一硬编码了清理函数，却没有实现一个清理机制！

甚至在这后面还有一段注释：坑爹啊。。。

再往下看，在Py_Finalize()的最后一行终于出现了本篇的另一个主角：call_ll_exitfuncs(); 这个函数的内容很简单：逐一执行 exitfuncs 这个数组里保存的函数。而 exitfuncs 这个数组的内容，则是由 Py_AtExit() 函数填进去的：

我最终采用的解决方案是这个：Py_AtExit()。

最后总结对比一下上述3种方案：

1. C语言的 atexit() ： 使用链表保存注册的函数，只要内存够，数量没限制。在Python完全结束后执行。
2. Python的 atexit 模块：使用 list 保存注册的函数，在register的时候还可以带参数，在Python解释器仍然完整的情况下执行，一般来说很够用；但由于使用的sys.exitfunc可能会被其他脚本使用，并不能100%保证有效，故，有强迫症的慎用。或者应当在doc里明确说明。
3. Python C API的 Py_AtExit() ：在Python环境几乎完全结束的时候被调用，最多只能注册32个函数（所以最好要检查返回值）。其实从流程上来说，在这之后马上就是main的return或者exit()函数调用，所以跟atexit基本上差不多。

p.s. 另一个尝试但是失败了的方案：建立一个新的type X_Type，在它的tp_dealloc里头写入清理代码，以X_Type建立一个新的class X，在模块的初始化函数中new一个X，撂着，并期望Py_Finalize()里的PyGC_Collect()会把它回收掉。不知道还差了点什么，如果哪位大牛知道，还望不吝赐教。