from:http://blog.gslin.info/2005/11/network-programming-using-libevent-i.html
在課堂上學過 Unix Network Programming 後，我們知道在處理多 User 時會有幾種方法解決：
- 一個新的 Connection 進來，用
fork() 產生一個 Process 處理。
- 一個新的 Connection 進來，用
pthread_create() 產生一個 Thread 處理。
- 一個新的 Connection 進來，丟入 Event-based Array，由 Main Process 以 Nonblocking 的方式處理所有的 I/O。
這三種方法當然也都有各自的缺點：
- 用
fork() 的問題在於每一個 Connection 進來時的成本太高。
- 用 Multi-thread 的問題在於 Thread-safe 與 Deadlock 問題難以解決，另外有 Memory-leak 的問題要處理。
- 用 Event-based 的方式在於實做上不好寫，尤其是要注意到事件產生時必須 Nonblocking，於是會需要實做 Buffering 的問題，而 Multi-thread 所會遇到的 Memory-leak 問題在這邊會更嚴重。而在多 CPU 的系統(tǒng)上沒有辦法使用到所有的 CPU resource。
當然，針對前面兩項有各自的解法：
- 以 Poll 的方式解決：當一個 Process 處理完一個 Connection 後，不直接死掉，而繼續(xù)回到 accept() 的狀態(tài)繼續(xù)處理，但這樣會遇到 Memory-leak 的問題，於是採用這種方式的人通常會再加上「處理過 N 個 Connection 後死掉，由 Parent Process 再
fork() 一隻新的」。最有名的例子是 Apache 1.3。
- Thread-safe 的問題可以透過自己撰寫，或是尋找其他 Thread-safe Library 直接使用。Memory-leak 的問題可以試著透過 Garbage Collection Library 分析出來。Apache 2.0 的 Thread MPM 就是使用這個模式。
然而，目前高效率的 Server 都偏好採用 Event-based，一方面是沒有 Create Process/Thread 所造成的 Overhead，另外一方面是不需要透過 Shared Memory 或是 Mutex 在不同的 Process/Thread 之間交換資料。
然而，Event-based 在實做上的幾個複雜的地方在於：
select() 與 poll() 的效率過慢，造成每次要判斷「有哪些 Event 發(fā)生」這件事情的成本很高，這在 BSD 支援 kqueue()、Linux 支援 epoll()、Solaris 支援 /dev/poll 後就解決了，但這兩組 Function 都不是 Standard，於是在不同的平臺上就必須再改一次。
- 因為 Nonblocking，所以在
write() 或是 send() 時滿了需要自己 Buffering。
- 因為 Nonblocking，所以不能使用
fgets() 或是其他類似的 function，於是需要自己刻一個 Nonblocking 的 fgets()。但是使用者所丟過來的資料又不能保證在一次 read() 或 recv() 就有一行，於是要自己做 Buffering。
實際上這三件事情在
libevent 都有 Library 處理掉了。
另外值得注意的一點在於
libevent 使用的是 3-clause BSD license 而非 GPL，所以在不想公開程式碼 (像是商業(yè)用途) 的情況下會比其他的 Library 適合。