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