1、freebsd裡的kqueue和linux 2.6下的epoll
兩個東西極其相似，寫好了一個之後，移到別外一個平台下，只要稍作修改就可以了，原理是一樣，個人認為，從功能角度來盾kqueue比epoll靈活得多。在寫kqueue的時候，內核幫你考慮好了不少東西。但是從效率來看，從我作的壓力測試來看epoll比kqueue強。看看我的實驗結果吧
客戶端： linux ,P3，256M ，pthread多線程程序，開1萬個線程，可是實際運行結果是，在linux2.4上只能打開4000多個線程的時候就報資源不足，郁悶了好久，不知道是什麼資源，最大打開文件數是夠了，內存也夠（通過設置16k的棧空間）。後來把客戶端移到linux2.6內核下，很快開出1萬個線程來了。
epoll服務器端：P3，256M，在一萬個並發線程下，面不改色，有條不紊地處理著數據，並發數能達到8000個連接。
kqueue服務器端：結果比較失望，在只能一條隊列的情況下，並發數只能到2000，然後在客戶端的讀取數據時就會出現"connect reset by peer"的錯誤。後來改用了兩條隊列，一條用來接收新連接，一條用來處理原有的連接。在這種情況下，並發數也只能到3000，然後又會陸陸續續出現連接的錯誤。
2、關於pthread庫的內容，加深了一下了解，學會了幾個新的調用。
3、關於freebsd和linux上的一些系統調置方面的東西。
最大打開文件數，在linux，直接用ulimit -a可以看到，並用ulimit進行修改，運行時有效。在freebsd下，用sysctl -a|grep kern.maxfilesperproc 來查詢，也可能直接修改。
