Felix021

看源码的时候经常要在某一类文件里面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()会把它回收掉。不知道还差了点什么，如果哪位大牛知道，还望不吝赐教。

昨天@Zind同学找到我之前的一篇blog(已经修改)，里面提到了mysql_ping和MYSQL_OPT_RECONNECT的一些事情。

之所以写那篇blog，是因为去年写的一些代码遇到了“2006:MySQL server has gone away”错误。这个问题是因为wait_timeout这个参数的默认值是28800，也就是说，如果一个连接连续8个小时没有任何请求，那么Server端就会把它断开。在测试环境中一个晚上没有请求很正常……于是第二天早上来的时候就发现这个错误了。

其实我有考虑这个问题的，真的……因为我知道php里面有个函数叫做mysql_ping()，PHP手册上说：“mysql_ping() 检查到服务器的连接是否正常。如果断开，则自动尝试连接。本函数可用于空闲很久的脚本来检查服务器是否关闭了连接，如果有必要则重新连接上。”

回想起来，以前真是很傻很天真。根据MySQL官方C API里mysql_ping()的文档："Checks whether the connection to the server is working. If the connection has gone down and auto-reconnect is enabled an attempt to reconnect is made. ... Auto-reconnect is disabled by default. To enable it, call mysql_options() with the MYSQL_OPT_RECONNECT option"，也就是说，它实际上还依赖于MYSQL_OPT_RECONNECT这个配置，而这个配置默认（自5.0.3开始）是关闭的！

虽然想起来很愤怒很蛋疼，不过看到 libmysql/client.c: mysql_init() 里的注释就淡定了：


好吧，既然有问题，那就正视它。解决办法是调用 mysql_options ，将MYSQL_OPT_RECONNECT设置为1:


但是!! 在mysql 5.0.19 之前，mysql->reconnect = 0 这一句是放在 mysql_real_connect() 里面的！也就是说，如果你不能像处理其他选项一样，而是必须在mysql_real_connect()之前设置MYSQL_OPT_RECONNECT，坑爹啊！

好吧好吧，总之，关于坑的问题暂告一段落，结论就是，不管是哪个版本，如果你想要启用自动重连，最好都是在mysql_real_connect()之后，反正不会错。

然后这篇的重点来了（前面似乎太罗嗦了点）：MYSQL_OPT_RECONNECT的文档里头说了，这个选项是用来启用/禁用（当发现连接断开时的）自动重连，那么，MYSQL什么时候会发现链接断开呢？

这个问题可能太大了，不过不妨先去追一下，mysql_ping()做了啥。

下载源码 http://cdn.mysql.com/Downloads/MySQL-5.1/mysql-5.1.67.tar.gz ，解压以后ctags -R，再vim -t mysql_ping ，马上就定位到了，似乎太简单了点：

好吧，看来关键在于这个simple_command了。ctrl+]，原来是这样：

好吧，先去追一下MYSQL，里头有个 const struct st_mysql_methods *methods ，再追一下 st_mysql_methods ....

坑爹啊！又是这种鸟代码！蛋疼的C语言！struct只有属性没有方法！没办法，只能暴力了：


果断追到client_methods:
也就是说simple_command最后调用了cli_advanced_command这个函数。前面的 simple_command(mysql,COM_PING,0,0,0) 相当于是调用了 cli_advanced_command(mysql, COM_PING, 0, 0, 0, 0, 0, NULL) 。

这个函数做了啥呢。。。其实也不复杂：
1. 设置默认返回值为1 （意外出错goto时被返回）
2. 设置sigpipe的handler（以便忽略它）
3. 如果 mysql->net.vio == 0 ，那么调用mysql_reconnect重连，失败的话就返回1
4. mysql没准备好，返回1
5. 清除之前的信息（错误码、缓冲区、affected_rows）等等
6. 调用net_write_command将命令发送给server，如果失败：
    6.1 检查错误信息，如果是因为发送包太大，goto end
    6.2 调用end_server(mysql)关闭连接
    6.3 调用mysql_reconnect尝试重连，如果失败goto end
    6.4 再次调用net_write_command将命令发送给server，失败则goto end
7. 设置result = 0（发送成功）
8. 如果参数中要求检查server的返回，则读取一个packet进行检查（失败的话就result=1）
9. (end标签)
10. 恢复sigpipe
11. 返回result

可以看到，这里两次调用了mysql_reconnect，但都是有条件的：第一次是在mysql->net.vio == 0的情况下，第二次是net_write_command失败且不是因为包太大的情况。vio相关的代码看得一头雾水，实在找不出头绪，于是决定暴力一点：直接修改这个函数，加入一堆fprintf(stderr, ...)（具体加在哪里就不说了，反正使劲塞就是了），然后写了一个C代码：

运行输出：

根据fprintf的输出，发现在正常情况下，mysql->net.vio这个指针并不等于0，所以第一个mysql_reconnect不会被调用。而net_write_command也是正确执行，第二个reconnect也没被调用。

而在执行完一个query，然后重启mysql server再执行query (mysql_query => mysql_real_query => mysql_send_query => cli_advanced_command)，就会发现，mysql->net.vio仍然不等于0，但是net_write_command失败了，于是先调用了end_server()（这里面会将mysql->net.vio设置为0，不过不影响后面的流程...），然后调用了第二个reconnect，这个reconnect会调用mysql_init()以及mysql_real_query()执行一些初始化的命令，于是又回到cli_advanced_command，再一步一步回溯。。。

综上可知，如果设置了MYSQL_OPT_RECONNECT()，那么mysql_query()是可以完成自动重连的。实际上，由于cli_advanced_command会在必要情况下调用mysql_reconnect（实际上这个函数也只在这里被调用），因此，所有用到了cli_read_query_result的地方（或者simple_command），也都可以完成自动重连。

完结。

//混蛋，这篇纯粹是为了凑一月至少一篇这个目标啊！

这事儿其实只要有了拼音库，就挺简单的。我从 pinyin4j 这个项目里搞了一份出来。虽然这个库是为java写的，不过要提取倒是相当简单：到这里 下载pinyin4j-2.5.0.zip，解压得到里头的 lib/pinyin4j-2.5.0.jar ，再解压得到里头的 pinyindb/unicode_to_hanyu_pinyin.txt 。

这个文件的结构很简单，每一行的基本结构是这样的：
前面的 4E04 是汉字的Unicode编码，空格分隔，然后括号里面包含了所有读音（而且看起来像是按频率排序好了的），每个读音分别给出了拼音的声母韵母以及声调。

在这个基础上解析它就相当简单了。


当然，你也可以把它存入一个key/value数据库（memcachedb什么的就挺好）。以上面的例子的话，把一个字符串中的汉字转换成拼音就很简单了：


要注意的一点是，“驴”的拼音被标记为 lu:2 ，而不是打字时习惯使用的 lv ，如果有需要的，还得再加个简单的转换逻辑。

实际上这个库里头还支持通用拼音（貌似是台湾地区使用过的）等其他转换方式，有需要的同学可以自己考据一下其结构。

p.s. 在python里头可以用 unichr(0x4E04) 得到这个unicode对应的字符，也可以用 ord('率'.decode('utf-8'))  得到这个字符的unicode编码(注意替换字符的原始编码)。至于十进制和十六进制的转换，也很简单， hex(32768) 得到 '0x8000' 而int('0x8000', 16)就能得到32768。python真好用。

昨天关注了下 微信公众平台，的确是个好东西，赞一下tx近来的开放。

它的api 乍一看还是挺简单的，于是就写了个小东西玩玩。

但是在开发的过程中遇到了多个坑，通过有故事王国的@ctqmumu同学把问题转了过去。实际开发的过程中遇到了好几个问题，但是其他问题（包括发一条消息请求我两次）都莫名其妙消失了，只有一个问题（具体见后文）通过被喷的方式解决了。

总之最后是可以用了，于是多花了点时间，把代码完善了下，写好了注释和样例，放在了Google Code上面，有需要的同学可以拿去用。


下载地址：http://code.google.com/p/mmsdk/downloads/list
    注：目前callback url仅支持80端口(@2012.11.27)

#UPDATE 2012.11.29 添加了对图片消息的支持（样例）、对调试的支持（DUMP请求/回复的xml文件），测试SAE可用（调试功能除外）

== 分割线，下面是纯吐槽 ==