Les différentes solutions proposées
Beaucoup de personnes ont réfléchit au problème, souvent de façon isolées. Ces recherches ont donné naissance non pas à une seule solution /dev/epoll comme celle que vous pouvez découvrir à travers ce site, mais une multitude que nous pouvons regrouper en deux catégories distinctes : celles au fonctionnement continue (level-triggered) et celles au fonctionnement par impultions (edge-triggered).
La différence entre ces deux catégories viens du traitement des
signaux : Dans le premier cas nous traitons les signaux de façon immédiate,
ce procédé à l'avantage de répondre immédiatement
à la requète du client, mais en cas de surcharge le requètes,
ce service monopolise toutes les ressources et fige la machine.
Dans le second cas, le noyau indique au service à quel moment il peut
traiter ces réceptions d'évènement. Ce qui permet de ne
quasiement pas connaitre de surcharge. par contre, les évèments
sont traités en mode différés et par conséquent
le serveur met plus de temps pour traiter la requète du client.
Les méthodes au traitement des signaux de manière continue
Les méthodes traditionnelles :
select( )
poll( )
Les nouveautées :
/dev/poll
Un patch est accessible au public à partir de mai 2000.
Ce patch a été dévelloppé par SUN pour patcher un
Solaris 8.
Cette version permettait de gagner 10% de performances par rapport au traditionnel
poll( ) lorsque le serveur était chargé par 750 clients.
kqueue (FreeBSD Kernel Queues)
Voir ci-dessous car il est possible de choisir la méthode de fonctionnement
de cette solution.
Les méthodes au traitement des signaux de manière impultionnelle
kqueue (FreeBSD Kernel Queues)
La version de FreeBSD 5.0 supporte une alternative à poll( ) appelée
kqueue( )/kevent( ). Cette version supporte les deux méthodes
: la méthode continue et la méthode impultionnelle.
Son fonctionnement est approximativement identique à /dev/poll :
On appèle kqueue( ) pour allouer un objet d'écoute. Puis, pour
changer les évenements que vous êtes entrain d'écouter ou
pour récupérer la liste des évenements reçus, on
appèle kevent( ) sur le descripteur retourné par kqueue( ).
En octobre 2000, on s'apperçoit d'un bug dans kqueue( ) :
Lorsque kqueue( ) bloque, tout le processus est bloqué et non pas uniquement
le thead appelé.
Realtime Signals
Cette méthode est apparue et a été directement implémentée
dans les noyaux linux 2.4.
Elle s'appuye principalement sur la méthode poll( ). Elle s'occupe simplement
de temporiser les signaux échangés par cette méthode.
Signal-per-fd
Cette méthode est une alternative à la méthode Realtime
Signals et parrait plus performante sur papier.
Malheureusement, la mise en application de cette méthode souffre de quelques
problèmes de stabilité.
/dev/epoll
Est apparue le 11 juillet 2001 par Davide Libenzi.
La méthode étudiée sur ce site: une veritable alternative
au Realtime Signals. Son schéma est plus performant que ce dernier.
Son fonctionnement ressemble de loin à /dev/poll.
Afin de comparer les performances de ces différentes solutions, je vous propose de passer aux tests comparatifs.