在課堂上學過 Unix Network Programming 後，我們知道在處理多 User 時會有幾種方法解決：
然而，Event-based 在實做上的幾個複雜的地方在於：
另外值得注意的一點在於 libevent 使用的是 3-clause BSD license 而非 GPL，所以在不想公開程式碼 (像是商業用途) 的情況下會比其他的 Library 適合。
- 一個新的 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 的系統上沒有辦法使用到所有的 CPU resource。
- 以 Poll 的方式解決：當一個 Process 處理完一個 Connection 後，不直接死掉，而繼續回到 accept() 的狀態繼續處理，但這樣會遇到 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 就是使用這個模式。
然而，Event-based 在實做上的幾個複雜的地方在於：
-
select()與poll()的效率過慢，造成每次要判斷「有哪些 Event 發生」這件事情的成本很高，這在 BSD 支援kqueue()、Linux 支援epoll()、Solaris 支援/dev/poll後就解決了，但這兩組 Function 都不是 Standard，於是在不同的平台上就必須再改一次。
- 因為 Nonblocking，所以在
write()或是send()時滿了需要自己 Buffering。 - 因為 Nonblocking，所以不能使用
fgets()或是其他類似的 function，於是需要自己刻一個 Nonblocking 的fgets()。但是使用者所丟過來的資料又不能保證在一次read()或recv()就有一行，於是要自己做 Buffering。
另外值得注意的一點在於 libevent 使用的是 3-clause BSD license 而非 GPL，所以在不想公開程式碼 (像是商業用途) 的情況下會比其他的 Library 適合。
