Quelle est la différence entre libev et libevent ?

Question

Ces deux librairies sont conçues pour l'ordonnancement asynchrone des entrées/sorties, et toutes deux utilisent epoll sous linux, et kqueue sous FreeBSD, etc.

À part les différences superficielles, je veux dire quelle est la VRAIE différence entre ces deux bibliothèques ? en ce qui concerne l'architecture, ou la philosophie de conception ?

Answer 1

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 rendait difficile l'utilisation de libevent en toute sécurité dans des environnements multithreads, les structures de watcher sont grandes parce qu'elles combinent les entrées/sorties, le temps et les gestionnaires de signaux en un seul élément, les composants supplémentaires tels que les serveurs http et dns ont souffert d'une mauvaise qualité d'implémentation et des problèmes de sécurité qui en résultaient, et les timers étaient inexacts et ne géraient pas bien les sauts de temps.

Libev a essayé d'améliorer chacun d'entre 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), en autorisant des types d'événements supplémentaires tels que les minuteries basées sur l'horloge murale ou le temps monotone, les interruptions inter-threads, les observateurs de préparation et de vérification pour intégrer d'autres boucles d'événements ou pour être intégrés, etc.

Le problème des composants supplémentaires est "résolu" en n'en ayant pas du tout, ce qui permet à libev d'être petit et efficace, mais il faut aussi chercher ailleurs une bibliothèque http, car libev n'en a tout simplement pas (par exemple, il existe une bibliothèque très proche appelée libeio qui fait de l'E/S asynchrone, et qui peut être utilisée indépendamment ou avec libev, ce qui permet de faire un mélange).

Donc, en résumé, libev essaie de faire une seule chose (bibliothèque d'événements POSIX), et ce 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 qui consiste à faire une seule chose, aussi bien que possible.

Notez que c'est la philosophie de conception, que je peux affirmer avec autorité car j'ai conçu libev. C'est à 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 fois à quelle inexactitude de timer je faisais référence, et pourquoi libev ne supporte pas les IOCP sous Windows.

En ce qui concerne les minuteries, libevent programme les minuteries par rapport à un temps de base inconnu qui se trouve dans le futur, sans que vous le sachiez. Libev peut vous dire à l'avance quel temps de base il utilisera pour programmer les minuteries, ce qui permet aux programmes d'utiliser à la fois l'approche libevent et l'approche libev. De plus, libevent peut parfois expirer les minuteries plus tôt, en fonction du backend. Le premier problème est un problème d'API, le second est corrigeable (et a peut-être été corrigé depuis - je n'ai pas vérifié).

Quant au support IOCP, je ne pense pas qu'il soit possible de le faire, 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 handles autorisés sous Windows (par exemple, les sopckets utilisés par perl sont du "mauvais" type pour les IOCP). De plus, les IOCP ne supportent tout simplement pas les événements de readyness d'E/S, ils ne peuvent que faire des E/S réelles. Il existe des solutions de contournement pour certains types d'identifiants, comme la lecture d'un octet 0, mais là encore, cela limiterait encore plus les types d'identifiants que vous pouvez utiliser sous Windows et, de plus, cela reposerait sur un comportement non documenté qui n'est probablement pas partagé par tous les fournisseurs de sockets.

À ma connaissance, aucune autre bibliothèque d'événements ne prend en charge les IOCP sous Windows, non plus. Ce que libevent fait, c'est qu'en plus de la bibliothèque d'événements, elle vous permet de mettre en file d'attente des opérations de lecture/écriture qui peuvent ensuite être effectuées via des IOCP. Puisque libev ne fait pas les E/S pour vous, il n'y a aucun moyen d'utiliser les IOCP dans libev lui-même.

C'est en effet à dessein - libev essaie d'être petit et de ressembler à POSIX, et Windows ne dispose tout simplement pas d'un moyen efficace pour 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 l'un des nombreux autres frameworks qui font des E/S pour vous et peuvent donc utiliser des IOCP.

Answer 2

Le grand avantage de libevent pour moi, c'est le support intégré d'OpenSSL. L'interface Bufferevent, introduite dans la version 2.0 de libevent API, gère les connexions sécurisées presque sans douleur pour le développeur. Mes connaissances sont peut-être dépassées mais il semble que libev n'en tient pas compte.