Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] epoll - Notifications d'évènements d'entrées/sorties. [size=18] [b]Résumé[/b] [/size] [b]#include <sys/epoll.h>[/b] [size=18] [b]Description[/b] [/size] [b]epoll[/b] est une variante de [b]poll (2)[/b] que l'on peut déclencher par niveau ou par changement d'état, et monte bien en charge pour un grand nombre de descripteurs simultanés. Trois appels-système sont fournis pour configurer et commander un ensemble [b]epoll :[/b] [b]epoll_create (2),[/b] [b]epoll_ctl (2),[/b] [b]epoll_wait (2).[/b] Un ensemble [b]epoll[/b] est connecté à un descripteur de fichiers créé par [b]epoll_create (2).[/b] L'interêt pour certains descripteurs est ensuite enregistré avec [b]epoll_ctl (2).[/b] Enfin, l'attente effective démarre avec l'appel [b]epoll_wait (2).[/b] [size=18] [b]Notes[/b] [/size] L'interface de distribution d'évènement de [b]epoll[/b] est capable de se comporter en détection de niveau (Level Triggered - LT) ou en détection de changement d'état (Edge Triggered - ET). La différence entre ces mécanismes est décrite ci-dessous. Supposons que le scénario suivant se produise : [b]1[/b] [table][row][col]    [/col][col]Le descripteur de fichier qui représente le côté lecture d'un tube [b]( fd_lect )[/b] est ajouté dans un ensemble [b]epoll .[/b][/col][/row][/table] [b]2[/b] [table][row][col]    [/col][col]Celui qui écrie dans le tube envoie 2 Ko de données.[/col][/row][/table] [b]3[/b] [table][row][col]    [/col][col]Un appel à [b]epoll_wait (2)[/b] est effectué et renvoie [b]fd_lect[/b] comme descripteur de fichier prêt.[/col][/row][/table] [b]4[/b] [table][row][col]    [/col][col]Le lecture du tube lit 1 Ko de données depuis [b]fd_lect .[/b][/col][/row][/table] [b]5[/b] [table][row][col]    [/col][col]Un appel de [b]epoll_wait (2)[/b] est effectué.[/col][/row][/table] Si le descripteur [b]fd_lect[/b] a été ajouté à l'ensemble [b]epoll[/b] en utilisant l'attribut [b]EPOLLET ,[/b] l'appel [b]epoll_wait (2)[/b] réalisé à l'étape [b]5[/b] va bloquer malgré les données déjà présentes dans les buffers d'entrée du fichier. La raison en est que le mécanisme ET détecte les changements sur un périphérique supervisé entre l'état "aucune entrée/sortie possible" [b]( 0 )[/b] et l'état "entrée/sortie possible" [b]( 1 ).[/b] Dans l'exemple ci-dessus, un événement sur [b]fd_lect[/b] sera déclenché (en supposant que le buffer était vide à l'origine) à cause de l'écriture à l'étape [b]2 ,[/b] et l'événement est consommé dans [b]3 .[/b] Comme l'opération de lecture de l'étape [b]4[/b] ne consomme pas toutes les données du buffer (la condition "Entrées/sorties possibles" persiste), aucune transition [b]0[/b] -> [b]1[/b] ne peut se produire en [b]5 .[/b] Lorsqu'on emploie l'attribut [b]EPOLLET[/b] (Edge Triggered) de la fonction [b]epoll ,[/b] on devrait toujours utiliser des descripteurs non-bloquants pour éviter qu'une lecture ou une écriture bloque une tâche qui gère plusieurs descripteurs de fichiers. L'utilisation suggérée d [b]epoll[/b] avec l'interface en détection de changements [b]( EPOLLET )[/b] est décrite ci-dessous, avec les pièges à éviter. .SR [b]i[/b] [table][row][col]    [/col][col]ave des descripteurs non-bloquants ;[/col][/row][/table] [b]ii[/b] [table][row][col]    [/col][col]en attendant seulement après qu'un [b]read (2)[/b] ou un [b]write (2)[/b] ait renvoyé EAGAIN. .SE[/col][/row][/table] Au contraire, lorsqu'il est utilisé avec l'interface en détection de niveau [b]epoll[/b] est une alternative plus rapide à [b]poll (2),[/b] et peut être employé chaque fois que poll() est utilisé, car il utilise la même sémantique. [size=18] [b]Exemple dutilisation conseillÉe[/b] [/size] Tandis que l'utilisation de [b]epoll[/b] avec un déclenchement par niveau correspond à la même sémantique que [b]poll (2),[/b] le déclenchement par changement d'état nécessite plus d'explication pour éviter les cas de blocage. Dans cet exemple, le lecteur emploie une socket non-bloquante sur laquelle [b]listen (2)[/b] a été appelée. La fonction do_use_fd() va utiliser le nouveau descripteur de fichier, jusqu'à ce que EAGAIN soit renvoyé par [b]read (2)[/b] ou par [b]write (2).[/b] Une application fonctionnant par transition d'état devrait, après réception d'EAGAIN, enregistrer l'état en cours, afin que l'appel suivant de do_use_fd() continue avec le [b]read (2)[/b] ou le [b]write (2)[/b] où il s'est arrêté. .nf struct epoll_event ev, events; for(;;) { nfds = epoll_wait(kdpfd, events, maxevents, -1); for(n = 0; n < nfds; ++n) { if(events[n].data.fd == listener) { client = accept(listener, (struct sockaddr ) &local, &addrlen); if(client < 0){ perror("accept"); continue; } setnonblocking(client); ev.events = EPOLLIN \| EPOLLET; ev.data.fd = client; if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) { fprintf(stderr, "epoll set insertion error: fd=%dn", client); return -1; } } else do_use_fd(events[n].data.fd); } } .fi Lorsqu'on utilise une détection de changement d'états, pour des raisons de performances, il est possible d'ajouter le descriptuer de fichier dans l'interface epoll [b]( EPOLL_CTL_ADD )[/b] une fois, en spécifiant [b]( EPOLLIN \| EPOLLOUT ).[/b] Ceci évite de basculer sans cesse entre [b]EPOLLIN[/b] et [b]EPOLLOUT[/b] lors des appels [b]epoll_ctl (2)[/b] avec [b]EPOLL_CTL_MOD .[/b] [size=18] [b]Questions et reponses (de la liste linux-kernel)[/b] [/size] .SR [b]Q1 [/b] [table][row][col]    [/col][col]Que se passe-t-il si on ajoute deux fois le même fd dans un ensemble epoll ?[/col][/row][/table] [b]A1 [/b] [table][row][col]    [/col][col]On aura probablement l'erreur EEXIST. Toutefois, il est possible que deux threads puisse ajouter le même fd deux fois. Sans conséquences fâcheuses.[/col][/row][/table] [b]Q2 [/b] [table][row][col]    [/col][col]Deux ensemples [b]epoll[/b] peuvent-ils attendre le même fd? Si oui, les événements seront-t-ils reportés sur des deux ensembles [b]epoll[/b] en même temps ?[/col][/row][/table] [b]A2[/b] [table][row][col]    [/col][col]Oui. Toutefois, c'est peu recommandé. Oui, l'événement sera rapporté pour les deux.[/col][/row][/table] [b]Q3[/b] [table][row][col]    [/col][col]Peut-on utiliser le descripteur [b]epoll[/b] lui-même avec poll/epoll/select ?[/col][/row][/table] [b]A3[/b] [table][row][col]    [/col][col]Oui.[/col][/row][/table] [b]Q4 [/b] [table][row][col]    [/col][col]Que se passe-t-il si le descripteur de [b]epoll[/b] est inséré dans son propre ensemble ?[/col][/row][/table] [b]A4[/b] [table][row][col]    [/col][col]Cela échouera. Toutefois vous pouvez ajoutez le descripteur de [b]epoll[/b] dans un autre ensemble epoll. [/col][/row][/table] [b]Q5[/b] [table][row][col]    [/col][col]Puis-je envoyer le descripteur [b]epoll[/b] à travers une socket Unix vers un autre processus ?[/col][/row][/table] [b]A5[/b] [table][row][col]    [/col][col]Non.[/col][/row][/table] [b]Q6[/b] [table][row][col]    [/col][col]Est-ce que la feermeteur d'un descripteur le supprime automatiquement d'un ensemble [b]epoll ?[/b][/col][/row][/table] [b]A6[/b] [table][row][col]    [/col][col]Oui.[/col][/row][/table] [b]Q7 [/b] [table][row][col]    [/col][col]Si plus d'un événement survient entre deux appels [b]epoll_wait (2),[/b] sont-ils combinés ou rapportés séparément ?[/col][/row][/table] [b]A7[/b] [table][row][col]    [/col][col]Ils sont combinés..[/col][/row][/table] [b]Q8[/b] [table][row][col]    [/col][col]Est-ce qu'une opération sur un descripteur affecte les événements déjà collectés mais pas encore rapportés ?[/col][/row][/table] [b]A8[/b] [table][row][col]    [/col][col]Vous pouvez faire deux choses sur un descripteur existant. Une suppression serait sans signification dans ce cas. Une modification re-vérifie les entrées/sorties disponibles.[/col][/row][/table] [b]Q9[/b] [table][row][col]    [/col][col]Dois-je lire/écrire sans cesse un descripteur jusqu'à obtenir EAGAIN avec l'attribut [b]EPOLLET[/b] (Edge Triggered behaviour) ?[/col][/row][/table] [b]A9[/b] [table][row][col]    [/col][col]Non. La réception d'un événement depuis [b]epoll_wait (2)[/b] suggère qu'un descripteur est prêt pour l'opération d'E/S désirée. Vous devez le considérer prêt jusqu'au prochain EAGAIN. Quand et comment utiliser le descripteur dépend de vous. De plus, la disponibilité des entrées/sorties peut-être vérifiée par la quantité de données lues ou écrites avec le descripteur. Par exemple, si vous appelez [b]read (2)[/b] en demandant la lecture d'une certaine quantité de données et que [b]read (2)[/b] en renvoie moins, vous pouvez être sûrs d'avoir consommé tout le buffer d'entrée pour le descripteur. La même chose est vraie pour l'appel-système [b]write (2).[/b] .SE [/col][/row][/table] [size=18] [b]PiÈges possibles, et solutions[/b] [/size] .SR [b]o Faux Positifs (Edge Triggered)[/b][/col][/row][/table] [table][row][col]    [/col][col]Il est possible que durant une lecture (en supposant que vous lisez en boucle en attendant EAGAIN), des données supplémentaires arrivent en second événement. Bien que ces données soient lues tout de suite, l'appel suivant de [b]epoll_wait (2)[/b] sur le descripteur dira qu'il y a un événement "lecture possible" alors qu'il a déjà été consommé. [b]1[/b] [table][row][col]    [/col][col]Une certaine quantité de données arrive sur un descripteur surveillé.[/col][/row][/table] [b]2[/b] [table][row][col]    [/col][col]Un appel à [b]epoll_wait (2)[/b] renvoit le descripteur repéré.[/col][/row][/table] [b]3[/b] [table][row][col]    [/col][col]Un autre bloc de données arrive sur la même descripteur.[/col][/row][/table] [b]4[/b] [table][row][col]    [/col][col]Le descripteur est signalé en interne comme prêt.[/col][/row][/table] [b]5[/b] [table][row][col]    [/col][col]Un appel à [b]read (2)[/b] consomme toutes les données disponibles.[/col][/row][/table] [b]6[/b] [table][row][col]    [/col][col]Un autre appel à [b]epoll_wait (2)[/b] renverra le descripteur ci-dessus même si aucune donnée n'est disponible, ainsi l'appel suivant de [b]read (2)[/b] renverra EAGAIN.[/col][/row][/table] Dans le cas de descripteurs non-bloquants, cela fera échouer immédiatement la lecture suivante avec l'erreur EAGAIN. Dans le cas de descripteurs bloquants, on restera en attente pour lire des données non encore présentes. L'auteur recommande de ne pas utiliser de descripteur bloquant avec le mécanisme de détection de changement d'état (ET). Pour traiter ce cas, une possibilité est de marquer le descripteur comme prêt dans sa structure de données associée après la réception du premier événement, puis d'ignorer les événements tant qu'il est dans l'état prêt. Lorsque vous lisez jusqu'à recevoir EAGAIN, effacez le bit d'état prêt avant de rappeler [b]epoll_wait (2)[/b] sur ce descripteur. [b]o Famine (Edge Triggered)[/b][/col][/row][/table] [table][row][col]    [/col][col]S'il y a un gros volume d'entrées/sorties, il est possible qu'en essayant de les traiter, d'autres fichiers ne soient pas pris en compte, ce qu'on appelle un cas de famine. Ce n'est pas spécifique à [b]epoll .[/b] La solution est de maintenir une liste de descripteurs prêts et de les marquer comme tels dans leur structure associée, permettant à l'application de savoir quels fichiers traiter, en organisant l'ordre au mieux. Ceci permet aussi d'ignorer les événments ultérieurs sur un descripteur prêt. [b]o Utilisation d'un cache d'événements...[/b][/col][/row][/table] [table][row][col]    [/col][col]Si vous utilisez un cache d'événement, ou stockez tous les descripteurs renvoyés par [b]epoll_wait (2),[/b] alors assurez vous de disposer d'un moyen de marquer dynamiquement leurs fermetures (causées par un événement précédent). Supposons que vous recevez 100 événements de [b]epoll_wait (2),[/b] et que l'événement 47 implique de fermer le descripteur 13. Si vous supprimez la structure et utilisez close(), alors votre cache peut encore contenir des événements pour ce descripteur, et poser des problèmes de cohérence. Une solution est d'invoquer, pendant le traitement de l'événement 47, [b]epoll_ctl ( EPOLL_CTL_DEL )[/b] pour supprimer le descripteur 13, le fermer, et marquer sa structure associée comme supprimée. Si vous rencontrez un autre événement pour le descripteur 13 dans votre traitement, vous verrez qu'il a été supprimé précédement, sans que cela ne prête à confusion. .SE [size=18] [b]Conformité[/b] [/size] [b]epoll (4)[/b] est une API introduie dans Linux 2.5.44. Son interface devrait être finalisée depuis le 2.5.66. [size=18] [b]Voir aussi[/b] [/size] [b]epoll_ctl (2),[/b] [b]epoll_create (2),[/b] [b]epoll_wait (2)[/b] [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 2003
Fichier