Quelle est la différence entre libev et libevent?

Les deux bibliothèques sont conçues pour la planification des E / S asynchrones, et toutes deux engagent epoll sur Linux, et kqueue sur FreeBSD, etc.

Sauf les 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 des variables globales rendait difficile l'utilisation de libevent en toute sécurité dans les environnements multithread, les structures watcher sont grandes car elles combinent les E / S, le temps et le signal gestionnaires en un, les composants supplémentaires tels que les serveurs http et dns souffraient d'une mauvaise qualité d'implémentation et de problèmes de sécurité qui en résultaient, et les minuteries étaient inexactes et ne supportaient 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), permettant des les 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éparent et vérifient les observateurs 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 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 liée appelée libeio qui effectue des E / S asynchrones, qui peuvent être utilisées indépendamment ou avec libev, afin que vous puissiez mélanger et assortir).

Bref, 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 bloquantes, serveur http, client DNS).

Ou, encore plus court, libev essaie de suivre la philosophie de la boîte à outils UNIX de ne faire qu'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. Que ces objectifs de conception aient réellement été atteints ou que la philosophie soit basée sur des principes solides, c'est à vous d'en juger.

Mise à jour 2017:

On m'a demandé à plusieurs reprises à quelle inexactitude de la minuterie je me référais, et pourquoi libev ne prend pas en charge les IOCP sous Windows.

En ce qui concerne les minuteries, libevent planifie les minuteries par rapport à une heure de base inconnue dans le futur, sans que vous le sachiez. Libev peut vous dire à l'avance quelle heure de base il utilisera pour planifier les minuteries, ce qui permet aux programmes d'utiliser à la fois l'approche libevent et l'approche libev. De plus, libevent expirait parfois prématurément les temporisations, 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 soutien de l'IOCP - je ne pense pas que cela puisse être fait, 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 descripteurs autorisés sur Windows (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 disponibilité d'E / S, ils ne peuvent faire que des E / S réelles. Il existe des solutions de contournement pour certains types de descripteurs, comme effectuer une lecture factice de 0 octet, mais encore une fois, cela limiterait encore plus les types de descripteurs que vous pouvez utiliser sur Windows et dépendrait en outre d'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 sur Windows. En plus de la bibliothèque d'événements, libevent 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 semblable à 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 frameworks qui effectuent des E / S pour vous et peuvent donc utiliser les 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 effort pour le développeur. Peut-être que ma connaissance est dépassée, mais il semble que libev ne le supporte pas.