Đối với triết lý thiết kế, libev được tạo ra để cải thiện một số quyết định về kiến trúc trong tự do, ví dụ: việc sử dụng biến toàn cầu khiến việc sử dụng libevent an toàn trong môi trường đa luồng khó khăn hơn, các cấu trúc watcher lớn vì chúng kết hợp I / O, thời gian và tín hiệu các trình xử lý trong một, các thành phần bổ sung như máy chủ http và dns có chất lượng triển khai kém và các vấn đề bảo mật dẫn đến, đồng thời bộ định thời không chính xác và không đối phó tốt với thời gian.
Libev đã cố gắng cải thiện từng điều này, bằng cách không sử dụng các biến toàn cục mà sử dụng ngữ cảnh vòng lặp cho tất cả các hàm, bằng cách sử dụng các trình theo dõi nhỏ cho từng loại sự kiện (trình theo dõi I / O sử dụng 56 byte trên x86_64 so với 136 đối với libevent), cho phép thêm các loại sự kiện, chẳng hạn như bộ định thời dựa trên thời gian treo tường so với thời gian đơn âm, ngắt giữa các luồng, chuẩn bị và kiểm tra trình theo dõi để nhúng các vòng sự kiện khác hoặc được nhúng, v.v.
Vấn đề thành phần bổ sung được "giải quyết" bằng cách hoàn toàn không có chúng, vì vậy libev có thể nhỏ và hiệu quả, nhưng bạn cũng cần phải tìm thư viện http ở nơi khác, bởi vì libev đơn giản là không có (ví dụ: có thư viện rất liên quan được gọi là libeio thực hiện I / O không đồng bộ, có thể được sử dụng độc lập hoặc cùng với libev, vì vậy bạn có thể trộn và kết hợp).
Tóm lại, libev cố gắng làm một việc duy nhất (thư viện sự kiện POSIX) và điều này theo cách hiệu quả nhất có thể. Libevent cố gắng cung cấp cho bạn giải pháp đầy đủ (lib sự kiện, thư viện I / O không chặn, máy chủ http, máy khách DNS).
Hoặc, ngắn hơn nữa, libev cố gắng tuân theo triết lý hộp công cụ UNIX là chỉ làm một việc, càng tốt càng tốt.
Lưu ý rằng đây là triết lý thiết kế, mà tôi có thể nêu với thẩm quyền vì tôi đã thiết kế libev. Liệu những mục tiêu thiết kế này đã thực sự đạt được hay chưa, hay triết lý có dựa trên các nguyên tắc đúng đắn hay không, là tùy thuộc vào bạn đánh giá.
Cập nhật năm 2017:
Tôi đã được hỏi nhiều lần về độ chính xác của bộ đếm thời gian mà tôi đề cập đến và tại sao libev không hỗ trợ IOCP trên windows.
Đối với bộ hẹn giờ, libevent lên lịch cho bộ hẹn giờ liên quan đến một số thời gian gốc không xác định trong tương lai mà bạn không biết. Libev có thể cho bạn biết trước thời gian cơ sở mà nó sẽ sử dụng để lên lịch hẹn giờ, điều này cho phép các chương trình sử dụng cả cách tiếp cận tự do và cách tiếp cận libev. Hơn nữa, đôi khi libevent sẽ hết hạn sớm, tùy thuộc vào phụ trợ. Sự cố trước là vấn đề API, vấn đề thứ hai có thể sửa được (và có thể đã được khắc phục kể từ đó - tôi đã không kiểm tra).
Đối với hỗ trợ IOCP - tôi không nghĩ có thể thực hiện được, vì IOCP đơn giản là không đủ mạnh. Đối với một điều, họ cần một loại ổ cắm đặc biệt, điều này sẽ hạn chế bộ xử lý được phép trên các cửa sổ hơn nữa (ví dụ: các chân cắm được perl sử dụng là loại "sai" cho IOCP). Hơn nữa, IOCP chỉ đơn giản là không hỗ trợ các sự kiện I / O sẵn sàng, chúng chỉ có thể thực hiện I / O thực tế. Có một số giải pháp thay thế cho một số loại xử lý, chẳng hạn như thực hiện đọc 0 byte giả, nhưng một lần nữa, điều này sẽ hạn chế các loại xử lý bạn có thể sử dụng trên windows và hơn nữa sẽ dựa trên hành vi không có tài liệu mà có thể không được chia sẻ bởi tất cả các nhà cung cấp socket .
Theo hiểu biết của tôi, không có thư viện sự kiện nào khác hỗ trợ IOCP trên windows. Những gì libevent làm là, ngoài thư viện sự kiện, nó cho phép bạn xếp hàng đợi các hoạt động đọc / ghi mà sau đó có thể được thực hiện thông qua IOCP. Vì libev không thực hiện I / O cho bạn, không có cách nào để sử dụng IOCP trong chính libev.
Điều này thực sự là do thiết kế - libev cố gắng trở nên nhỏ và giống POSIX, và các cửa sổ đơn giản là không có cách hiệu quả để nhận các sự kiện I / O kiểu POSIX. Nếu IOCP quan trọng, bạn phải tự sử dụng chúng hoặc thực sự sử dụng một số trong nhiều khuôn khổ khác làm I / O cho bạn và do đó có thể sử dụng IOCP.