Quelle est la différence entre libev et libevent?
Les deux librairies sont conçues pour la planification des E/S asynchrones, et les deux engagent epoll sur linux et kqueue sur FreeBSD, etc.
Sauf différences superficielles, je veux dire quelle est la VRAIE différence entre ces deux bibliothèques? concernant l'architecture ou la philosophie du design?
En ce qui concerne la philosophie de conception, libev a été créé pour améliorer certaines des décisions architecturales de libevent, par exemple, l'utilisation de variables globales a rendu difficile l'utilisation de libevent en toute sécurité dans des environnements multithreads, les structures de surveillance sont grandes car elles combinent les E/S, l'heure et le signal en un seul gestionnaire, les composants supplémentaires tels que les serveurs http et dns ont souffert d'une mauvaise qualité d'implémentation et de problèmes de sécurité en résultant, et les temporisateurs étaient inexacts et ne faisaient pas bien face aux sauts dans le temps.
Libev a essayé d'améliorer chacun d'eux, en n'utilisant pas de variables globales mais en utilisant un contexte de boucle pour toutes les fonctions, en utilisant de petits observateurs pour chaque type d'événement (un observateur d'E/S utilise 56 octets sur x86_64 contre 136 pour libevent), permettant types d'événements tels que les minuteries basées sur l'horloge murale par rapport à l'heure monotone, les interruptions entre les threads, préparer et vérifier les observateurs pour incorporer d'autres boucles d'événements ou pour être incorporés, etc.
Le problème des composants supplémentaires est "résolu" en ne les ayant pas du tout, donc libev peut être petit et efficace, mais vous devez également chercher ailleurs une bibliothèque http, car libev n'en a tout simplement pas (par exemple, il y a un bibliothèque très apparentée appelée libeio qui fait des E/S asynchrones, qui peuvent être utilisées indépendamment ou avec libev, de sorte que vous pouvez mélanger et assortir).
Donc, en bref, libev essaie de faire une seule chose (bibliothèque d'événements POSIX), et cela de la manière la plus efficace possible. Libevent essaie de vous donner la solution complète (bibliothèque d'événements, bibliothèque d'E/S non bloquante, serveur http, client DNS).
Ou, encore plus court, libev essaie de suivre la philosophie de la boîte à outils UNIX de faire une seule chose, aussi bien que possible.
Notez que c'est la philosophie de conception, que je peux affirmer avec autorité parce que j'ai conçu libev. À vous de juger si ces objectifs de conception ont réellement été atteints ou si la philosophie est basée sur des principes solides.
Mise à jour 2017:
On m'a demandé à plusieurs reprises à quelle inexactitude de la minuterie je fais référence et pourquoi libev ne prend pas en charge les IOCP sur Windows.
En ce qui concerne les minuteries, libevent planifie les minuteries par rapport à une heure de base inconnue qui est dans le futur, sans que vous le sachiez. Libev peut vous dire à l'avance le temps de base qu'il utilisera pour planifier les temporisateurs, ce qui permet aux programmes d'utiliser à la fois l'approche libevent et l'approche libev. De plus, libevent expirait parfois les temporisateurs plus tôt, selon le backend. Le premier est un problème d'API, le second est réparable (et pourrait avoir été corrigé depuis - je n'ai pas vérifié).
Quant au support IOCP - je ne pense pas que ce soit possible, car les IOCP ne sont tout simplement pas assez puissants. D'une part, ils ont besoin d'un type de socket spécial, ce qui limiterait encore plus l'ensemble des poignées autorisées sur les fenêtres (par exemple, les sopckets utilisés par Perl sont du type "incorrect" pour les IOCP). De plus, les IOCP ne prennent tout simplement pas en charge les événements de préparation aux E/S, ils peuvent uniquement effectuer des E/S réelles. Il existe des solutions de contournement pour certains types de descripteurs, comme la lecture factice de 0 octet, mais là encore, cela limiterait encore plus les types de descripteurs que vous pouvez utiliser sur Windows et, en outre, dépendrait d'un comportement non documenté qui n'est probablement pas partagé par tous les fournisseurs de socket. .
À ma connaissance, aucune autre bibliothèque d'événements ne prend en charge les IOCP sur Windows non plus. Ce que libevent fait, en plus de la bibliothèque d'événements, il vous permet de mettre en file d'attente les opérations de lecture/écriture qui peuvent ensuite être effectuées via les IOCP. Puisque libev ne fait pas d'E/S pour vous, il n'y a aucun moyen d'utiliser les IOCP dans libev lui-même.
C'est en effet par conception - libev essaie d'être petit et de type POSIX, et Windows n'a tout simplement pas de moyen efficace d'obtenir des événements d'E/S de style POSIX. Si les IOCP sont importants, vous devez soit les utiliser vous-même, soit utiliser certains des nombreux autres cadres qui font des E/S pour vous et peuvent donc utiliser des IOCP.
Le grand avantage de libevent pour moi est le support OpenSSL intégré. L'interface Bufferevent, introduite dans la version 2.0 de l'API libevent, gère les connexions sécurisées presque sans douleur pour le développeur. Peut-être que mes connaissances sont obsolètes, mais il semble que libev ne le supporte pas.