web.py作为fast cgi部署到nginx上

部署方法都来自这个帖子：http://webpy.org/cookbook/fastcgi-nginx
我只是对一些细节进行补充说明

#perl 的正则表达式库
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.33.tar.gz
tar -zxvf pcre-8.33.tar.gz
cd pcre-8.33
./configure && make && make install
#openssl，注意，只有1.0.0才能和nginx一起编译通过
wget http://www.openssl.org/source/openssl-1.0.0.tar.gz
tar -zxvf openssl-1.0.0.tar.gz
#不用编译openssl
cd nginx-1.4.2
./configure --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.conf --pid-path=/usr/local/nginx/nginx.pid --without-select_module --without-poll_module --with-http_ssl_module --with-http_spdy_module --with-http_gunzip_module --with-http_gzip_static_module --with-openssl=/data/temp/openssl-1.0.0
make && make install
#
wget http://www.saddi.com/software/flup/dist/flup-1.0.1.tar.gz
tar -zxvf flup-1.0.1.tar.gz
cd flup-1.0.1
python setup.py build && python setup.py install

#

wget http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz

tar -zxvf spawn-fcgi-1.6.3.tar.gz

cd spawn-fcgi-1.6.3 && make && make install

#下面配置nginx

location / {

        fastcgi_param REQUEST_METHOD $request_method;

        fastcgi_param QUERY_STRING $query_string;

        fastcgi_param CONTENT_TYPE $content_type;

        fastcgi_param CONTENT_LENGTH $content_length;

        fastcgi_param GATEWAY_INTERFACE CGI/1.1;

        fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

        fastcgi_param REMOTE_ADDR $remote_addr;

        fastcgi_param REMOTE_PORT $remote_port;

        fastcgi_param SERVER_ADDR $server_addr;

        fastcgi_param SERVER_PORT $server_port;

        fastcgi_param SERVER_NAME $server_name;

        fastcgi_param SERVER_PROTOCOL $server_protocol;

        fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;

        fastcgi_param PATH_INFO $fastcgi_script_name;

        fastcgi_pass 127.0.0.1:9002;

}

#配置static目录

    location /static/ {

        root /path/to/www;

        if (-f $request_filename) {

           rewrite ^/static/(.*)$  /static/$1 break;

        }

    }

#启动spawn-fcgi

#vi my_web.py

# 加上 

#!/usr/bin/env python

# -*- coding: utf-8 -*-

#注意文件本身不能是utf-8编码的

chmod +x my_web.py

chown -R user_0:users  my_web/

spawn-fcgi -d /data/my_web -f /data/my_web/my_web.py -a 127.0.0.1 -p 9002 -u user_0 -g users -F 5

换成nginx后，整个站点快了好多，爽多了！

javascript: 破坏引用导致的BUG

用代码来解释：
var g_array = [1,2,3];
function MyClass(arr){
   this.make_bug = function(){
      arr = [4,5,6];
   }

   this.remove_one = function(){
      arr.shift(0);
   }
}

//
var obj = MyClass(g_array);
obj.make_bug();
obj.remove_one();
//可以发现，全局数组根本没有被更改
//因为make_bug里面，破坏了对全局数组的引用

一个坑：crontab中使用sudo

最近，一个进程总是无法被crontab拉起，加了日志观察后，发现这一句错误信息：
sudo: sorry, you must have a tty to run sudo

google一下发现这篇帖子：http://gcoder.blogbus.com/logs/49929050.html

解决办法为：
vi /etc/sudoers
#注释掉 Defaults    requiretty

搞定！

为什么64位下用python调用C库发生了崩溃

在64位下，把一些库封装成C函数，然后编译成so文件供python调用，结果发生了崩溃。
今天试验后发现：如果C函数返回void*等类型，把返回值赋值到python变量后被截断，只剩下低32位的值。
因此，如果C函数中的指针在0xffffffff以上的地址的时候，返回到python中就会被截断。如果再继续使用这个被截断后的地址值，就会发生崩溃。

下面是模拟崩溃的代码：
//C
void* create_object()
{
    return new int(0);
}

void free_object(void* obj)
{
    delete (int*)obj;
}

#python中这样调用
so = cdll.LoadLibrary('xxxx.so')
obj = so.create_object()  #这里被截断
so.free_object(obj)       #这里发生崩溃

=====================================================
解决办法也比较简单，不要通过返回值传递指针，而通过指针参数返回：

void create_object(uint64_t* out)
{
    *out = (uint64_t)new int(0);
}

void free_object(void* obj)
{
    delete (int*)obj;
}



#python中这样调用
so = cdll.LoadLibrary('xxxx.so')
obj = ctypes.c_ulonglong(0)
so.create_object(ctypes.byref(obj))
obj = ctypes.c_void_p(obj.value)
so.free_object(obj)


这里要注意：发现python中的对象的地址都在0xffffffff之内，所以使用byref没发现问题。
byref是否会截断指针，这个还没试验出来。

linux64下的一个链接问题: crtbeginT.o

尝试链接一个动态库，结果crtbeginT.o这个系统库出现错误：


g++ -o ttc_api_c.o -c ttc_api_c.cpp -g -Wall -Werror -O2 -fPIC
g++ -o ttc_api_c.so -shared ttc_api_c.o libttc.pic_64.a -static
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

百思不得其姐，还好搜索到这篇帖子：
https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/640734

采用文中的办法，酱紫解决了：

cd /usr/lib/gcc/x86_64-redhat-linux/4.4.6
cp crtbeginT.o crtbeginT.orig.o
cp crtbeginS.o crtbeginT.o