熟读而精思，循序而渐进，厚积而薄发。
于是，FastCGI，另一种类似的协议被提出了。顾名思义，该协议的提出就是要克服普通CGI程序性能低下的缺点，同时又具备普通CGI的所有优点。通信方式上，FastCGI与CGI大同小异，主要区别在于：
接口方面，有很多针对不同语言的FastCGI开发套件，保证了FastCGI与普通CGI具有很大的兼容性，普通CGI程序作极小的改动便可以以FastCGI的形式运行。
场景是这样的。我在写一个Nginx模块，该模块使用了MySQL的C客户端接口库libmysqlclient，当然mysqlclient还引用了其他的库，比如libm, libz, libcrypto等等。对于使用mysqlclient的代码来说，需要关心的只是mysqlclient引用到的动态库。大部分情况下，不是每台机器都安装有libmysqlclient，所以我想把这个库静态链接到Nginx模块中，但又不想把mysqlclient引用的其他库也静态的链接进来。
我们知道gcc的-static选项可以使链接器执行静态链接。但简单地使用-static显得有些’暴力’，因为他会把命令行中-static后面的所有-l指明的库都静态链接，更主要的是，有些库可能并没有提供静态库（.a），而只提供了动态库（.so）。这样的话，使用-static就会造成链接错误。
在StackOverflow上面提了How to do partial linking这个问题，但两天都没人搭理我，大概那些哥们儿也像中国人一样，圣诞狂欢呢吧。但最后一个叫Employed Russian的哥们给了一个链接，和我的问题相似（你很少能遇到独一无二的问题）。这个帖子唯一的一个解答解决了问题。
我之前的链接选项大致是这样的，
1 | CORE_LIBS="$CORE_LIBS -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib64 -lssl -lcrypto" |
这两天研究Nginx模块的实现机制，目的是写一个自己的module。调试过程中遇到一个诡异的问题，解决后发现是一个极小的失误，但这个’小臭虫’花掉我将近四个小时。
最终发现，问题起因于ngx_snprintf函数，这是Nginx自己实现的，类似C标准库中snprintf的一个函数（这是一个用户空间的函数 ）。ngx_snprintf的原型为，
1 2 3 | //~ core/ngx_string.h u_char * ngx_cdecl ngx_snprintf(u_char *buf, size_t max, const char *fmt, ...); |
问题确实很简单，调试并找出问题本也不应该太难。但遇到问题时，我首先想到的是自己对Nginx不是太熟悉，将注意力放在了周边环境，以为是对Nginx各模块的调用链不熟悉导致的。调试真是门学问，更多的是靠大量的代码经验和由此获得的面对问题的一种’直觉’。对，’直觉’，小工没有太多经验，需要很多规则来参照，专家却站在规则之上，靠直觉就可快速地定位、解决问题。
甚至可以可以使用nc建立文件的中转站。比如，从host1无法直连到host3，只能先连到host2再间接连到host3。如果想从host1向host3传输文件，可以在host2上面建立中转。每次直接传输是client/server还是server/client，都可以实现（当然，如果两台机器有防火墙相隔时，就另说了）：
1 2 3 4 | dutor@host2 $ nc -l 5198 | nc -l 5191 dutor@host2 $ # 使用 while true; do nc -l 5198 | nc -l 5191; done 可以建立持久的'中转站' dutor@host1 $ nc host2 5198 < stuff.tgz dutor@host3 $ nc host2 5191 | tar xzvf - |
nc是一个简单，强大，又可以信手拈来的工具，尽情发挥你的想象力吧。
我们还知道，类的静态成员函数是不需要绑定到特定对象上面的，所以我们就可以将worker声明为静态成员。
1 2 3 4 5 6 7 8 9 10 11 | class Thread { public: static void* worker(void* args) { //~ thread execution. } private: //~ here some data member. }; pthread_t tid; pthread_create(&tid, NULL, &Thread::worker, NULL); |
我们又知道，静态成岩函数是不能’直接’访问类的非静态成员（包括函数），因此，上面代码中worker即使属于class Thread的类域，但却无法访问这个类的成员，这让人十分不爽。哪位大牛说过来着？任何一个复杂的计算机问题，都可以通过中间层来解决。这里也可以建立一个中间层：使用静态成员函数创建线程，给该函数传递某个对象的地址作为参数，在该静态函数中就可以通过所传递对象的使用它的任何成员了。
传说中，存在这么一串神秘的字符，你把它们放到终端，然后回车，不消太久，你的机器就变植物人只能低电平复位重启了。这串神秘的字符看起来是这样的，
1 | dutor@home: ~$ :(){ :|:; };:& |
这是神马玩意儿呢？好的，现在听我的，把你的脑袋面对显示器逆时针旋转四分之一圆周，像不像一个张着血盆大口的长袍老怪？
严肃点，你看懂它的真相了吗？换种等价的写法，
1 | dutor@home: ~$ foo(){ foo|foo; };foo& |
其实就是“声明”了一个函数，然后在后台执行这个函数。在函数体内部，以管道的形式调用递归调用自身。第一种写法只是把函数名换成”:”产生的怪胎。
之前用了两年的meyu虚拟主机快到期了，出于各种应有和本不应有的需求，决定买VPS。linode的VPS名声一直不错，于是就买了。
简单介绍下过程，给希望购买VPS的朋友可以参考下。从决定购买到付款到开通到安装系统到部署各种环境，大约一个小时多一点。目前linode有多种不同规格的的VPS，采用Xen虚拟机，我选的是512M RAM/20G Storage的那款，价格是每月$19.95，可能稍贵，可性能和稳定性有保证。系统方面，linode支持各种主流Linux发行版，我暂时选了比较熟悉的Ubuntu Server 11.10，最新的30内核。Web服务器暂时选Apache2，考虑以后学习Nginx的时候换成Nginx。另外，linode在世界各地都有机房，当然要除了中国，我选了最近的东京，ping 70ms左右。
好吧，就这些。
core dump, 通常译作内存转储，core之所以译作内存，而不是核心，纯属“著名”的历史原因，因为早期的内存有一个叫磁芯（magnectic core）的东西。内存转储会在磁盘中产生一个文件，是某个进程在转储时刻的内存映像及寄存器等信息。内存转储通常发生在进程执行了有致命错误的指令时，常见的就是著了名的Segmentation fault，即段错误，而导致段错误的就是C/C++编程中经常发生的内存非法访问。内存转储操作由操作系统内核进行。当然，内存转储还可以是用户主动发起请求，内核执行转储。
内存转储对于程序调试是至关重要的。利用内存转储文件（core files）对程序进行调试是一种异步的静态调试，所谓异步是指异常发生与调试不是在同一时刻，所谓静态指的是core files保存的只是转储时刻进程的内存状态。比如，一个长期运行的服务程序，我们不知道哪里有bug，该bug何时被触发，这种情况下，利用异常发生时的转储文件就可以在一定程度上定位出异常发生的原因。另外，对于非致命性错误，比如死锁或者死循环，进程不会自动结束，通常内核也不会主动杀掉这种进程，这时用户就可以请求内核将该进程进行内存转储，以此来查看进程的运行状态（比如各进程的堆栈）。