greensea 的 blog

fusecompress 是个好东西，它可以用来透明地压缩磁盘上的文件，而且支持多种压缩方法和压缩等级。我已经把我的桂林计算姬上使用 Dropbox 同步的文件夹压缩过了，这样可以减小网络开销，ADSL的上行是很杯具的。反正我在 Dropbox 上的文件都是不用共享的，纯粹自己用，所以不存在麻烦别人的问题。

好，进入正题。我有一个4G的读卡器，在上面弄了一个 LiveUSB，直接安装 Ubuntu 9.10，但是 Ubuntu 在上面只有3G的空间可以使用，包括家目录。因为我只有这一个U盘，所以需要留出1G的空间用来储存需要动来动去的文件，学校的电脑清一色的 Windows，连实验考试都要求只能运行在 Windows 平台上，这是什么计算机系啊。

3G的空间放一个系统和家目录那算是非常小的了，所以压缩文件系统就成了一个不错的选择。另外，对于一些压缩率较高的文件，使用压缩文件系统以后可以减少磁盘开销。特别是对于存取速度较低的磁盘，效果更佳。比如我这个读卡器+4G的SD卡用 hdparm 测出来的速度就只有11MB左右。

首先写了一个找第N个素数的程序，使用很原始的算法，然后设定为找第10000个素数。
我本意是想弄一个线程来记录当前的搜索进度，这样就涉及两个变量，当前已经找到了第几个素数，以及当前正在测试的数。为了保证正确记录这两个变量，就弄了一个信号量来设定临界区。
于是奇异的现象就出现了，没有设置信号量之前整个程序运行时间是12.3秒左右，而使用了信号量之后，速度竟然降低到11.8秒左右，速度提高近5%。虽然不是每次测试都快0.5秒，但如果没有快0.5秒的话，就是差不多12.3秒。只会出现基本上速度相同，或者快0.5秒的情况看。
明明是加了信号量，需要内核去做一些事情，这些事情多多少少也会吃掉一些时间，如果说内核调用速度很快对运行速度基本上没有影响，那么有没有使用信号量的时间基本上一样也就算了，但问题是加了信号量之后运行速度竟然更快了，这也太诡异了的说。

随后我又给另一个代码段加了一个信号量，但是速度并没有变得比11.8秒更快，似乎11.8秒就是极限了

原因不明，先把这个现象记录下来好了。

首先这个CKEditor以前是叫做FCKEditor的。
最近在给YT弄新的在线编辑器，现在的TinyMCE似乎表现不怎么好，然后发现CKEditor的界面很好很强大，本地化工作也比TinyMCE好，于是就选用CKEditor了。

今天下午弄了好久总算把 pure-ftpd with libantixunlei 部署到64位系统上去了。期间调教了好久。
首先想起来长整型（long）在64位系统上是8字节，而在32位系统上是4字节。于是就出现了一些数据结构对齐的问题，这个问题弄下来以后，偶索性把所有的long都替换成了int，然后编译安装，一切顺利。
但是运行的时候，却发现主进程的消息处理线程阻塞死了，根据调试信息，子进程明明已经把消息发送出去了，但是消息处理线程硬是收不到，一直阻塞在msgrcv函数那里。
于是又折腾了好久，后来才想到，会不会是这个msg_buf_t里面用来标识消息类型的mtype是长整型的，如果这样的话，刚才我把所有的long替换成int，肯定影响到这里了。之前偶在网上看消息函数的时候，有些文章定义这个结构体的时候用的是整型，而有些文章用的是长整型，哎呀真是不严谨啊。
于是把这个结构体里面的 int mtype 改成 long mtype，编译安装运行，正常了……
所以说long和int一定要慎用啊……

最近发现，虽然以前做了很多东西，也解决了很多问题，看似也学会了解决很多问题。而实际上，因为有些东西是很少用到的，所以很容易就会忘记。等到某天想用的时候，虽然记得以前知道怎么做，也成功做过，但是到现在就想不起细节到底是怎样的了。所以看来啊，还是应该把这些东西记起来比较好。
于是这几天在cygwin下弄libantixunlei，先记下这些东西吧。如果以后再有新发现的话，继续追加。
顺便说个趣事，我用fork()函数产生子进程，产生到300多个的时候，Windows挂掉了，表现为图形界面凝固，怎么动都没反应，只能冷启。