zion - select_tut
Nom
select, pselect, FD_CLR, FD_ISSET, FD_SET, FD_ZERO - Multiplexage d'E/S synchrones
Résumé
#include <sys/time.h> #include <sys/types.h> #include <unistd.h> int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *utimeout); int pselect(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, const struct timespec *ntimeout, sigset_t *sigmask); FD_CLR(int fd, fd_set *set); FD_ISSET(int fd, fd_set *set); FD_SET(int fd, fd_set *set); FD_ZERO(fd_set *set); .fi
Description
select (ou pselect) est la fonction pivot de la plupart des programmes en C qui gèrent simultanément et de façon efficace plusieurs descripteurs de fichiers (ou sockets). Ses principaux arguments sont trois tableaux de descripteurs de fichiers : readfds, writefds, et exceptfds. select est généralement utilisé de façon à bloquer en attendant un "changement d'état" d'un ou plusieurs descripteurs de fichiers. Un "changement d'état" est signalé lorsque de nouveaux caractères sont mis à disposition sur le descripteur de fichier; ou bien lorsque de l'espace devient disponible au niveau des tampons internes du noyau permettant de nouvelles écritures dans le descripteur de fichier, ou bien lorsqu'un descripteur de fichier rencontre une erreur (dans le cas d'une socket ou d'un tube, une telle erreur est levée lorsque l'autre extrémité de la connexion est fermée). Pour résumer, select surveille simplement de multiples descripteurs de fichiers, et constitue l'appel Unix standard pour réaliser cette tâche. Les tableaux de descripteurs de fichier sont appelés ensembles de descripteurs de fichiers. Chaque ensemble est de type fd_set, et son contenu peut être modifié avec les macros FD_CLR, FD_ISSET, FD_SET, et FD_ZERO. On commence généralement par utiliser FD_ZERO sur un ensemble venant d'être créé. Ensuite, Les descripteurs de fichiers individuels qui vous intéressent peuvent être ajoutés un à un à l'aide de FD_SET. select modifie le contenu de ces ensembles selon les règles ci-dessous; Après un appel à select, vous pouvez vérifier si votre descripteur de fichier est toujours présent dans l'ensemble à l'aide de la macro FD_ISSET. FD_ISSET renvoie zéro si le descripteur de fichier est absent et une valeur non nulle sinon. FD_CLR retire un descripteur de fichier de l'ensemble bien que je n'en vois pas l'utilité dans un programme propre.
Arguments
readfds Cet ensemble est examiné afin de déterminer si des données sont disponibles en lecture à partir d'un de ses descripteurs de fichiers. Suite à un appel à select, readfds ne contient plus aucun de ses descripteurs de fichiers à l'exception de ceux qui sont immédiatement disponibles pour une lecture via un appel recv() (pour les sockets) ou read() (pour les tubes, fichiers et sockets). |
writefds Cet ensemble est examiné afin de déterminer s'il y a de l'espace afin d'écrire des données dans un de ses descripteurs de fichiers. Suite à un appel à select, writefds ne contient plus aucun de ses descripteurs de fichiers à l'exception de ceux qui sont immédiatement disponibles pour une écriture via un appel à send() (pour les sockets) ou write() (pour les tubes, fichiers et sockets). |
exceptfds Cet ensemble est examiné pour les exception ou les erreurs survenues sur les descripteurs de fichiers. Néanmoins, ceci n'est véritablement rien d'autre qu'une rumeur. exceptfds est en fait utilisé afin de détecter l'occurence de données hors-bande (Out Of Band). Les données hors bande sont celles qui sont envoyées sur une socket en utilisant le drapeau MSG_OOB, ainsi exceptfds s'applique en réalité uniquement aux sockets. Voir recv(2) et send(2) à ce sujet. Suite à un appel à select, exceptfds ne contient plus aucun de ses descripteurs de fichiers à l'exception de ceux qui sont disponibles pour une lecture de données hors-bande. Cependant, vous pouvez presque toujours lire uniquement un octet de données hors bande (à l'aide de recv()), et l'écriture de données hors bande (avec send) peut être effectuée à n'importe quel moment et n'est pas bloquante. Il n'y a donc pas de besoin d'un quatrième ensemble afin de vérifier si une socket est disponible pour une écriture de données hors bande. |
n Il s'agit d'un entier valant un de plus que n'importe lequel des descripteurs de fichiers de tous les ensembles. En d'autres termes, lorsque vous ajoutez des descripteurs de fichiers à vos ensembles, vous devez déterminer la valeur entière maximale de tous ces derniers, puis ajouter un à cette valeur, et la passer en argument n à select. |
utimeout
.nf struct timeval { long tv_sec; /* secondes */ long tv_usec; /* microsecondes */ }; .fi |
ntimeout
.nf struct timespec { long tv_sec; /* secondes */ long tv_nsec; /* nanosecondes */ }; .fi |
sigmask Cet argument renferme un ensemble de signaux non bloqués pendant un appel pselect (voir sigaddset(3) et sigprocmask(2)). Il peut valoir NULL, et, dans ce cas, il ne modifie pas l'ensemble des signaux non bloqués à l'entrée et la sortie de la fonction. Il se comporte alors de façon identique à select. |
Combinaison dÉvÉnements de signaux et de donnÉes
pselect doit être utilisé si vous attendez tout aussi bien un signal que des données d'un descripteur de fichier. Les programmes qui reçoivent les signaux comme des événements utilisent généralement le gestionnaire de signal uniquement pour lever un drapeau global. Le drapeau global indique que l'événement doit être traiter dans la boucle principale du programme. Un signal provoque l'arrêt de l'appel select (ou pselect) avec errno positionnée à EINTR. Ce comportement est essentiel afin que les signaux puissent être traités dans la boucle principale du programme, sinon select bloquerait indéfiniment. Ceci étant, la boucle principale implante quelque part une condition vérifiant le drapeau global. et l'on doit donc se demander : que se passe t il si un signal est levé après la condition mais avant l'appel à select ? La réponse est que select bloquerait indéfiniment, même si un signal est en fait en attente. Cette "race condition" est résolue par l'appel pselect. Cet appel peut être utilisé afin de débloquer des signaux qui ne sont pas censés être reçus si ce n'est durant l'appel à pselect. Par exemple, disons que l'événement en question est la fin d'un processus fils. Avant le démarrage de la boucle principale, nous bloquerions SIGCHLD en utilisant sigprocmask. Notre appel pselect débloquerait SIGCHLD en utilisant le masque de signal initial. Le programme ressemblerait à ceci:
.nf int child_events = 0; void child_sig_handler (int x) { child_events++; signal (SIGCHLD, child_sig_handler); } int main (int argc, char **argv) { sigset_t sigmask, orig_sigmask; sigemptyset (&sigmask); sigaddset (&sigmask, SIGCHLD); sigprocmask (SIG_BLOCK, &sigmask, &orig_sigmask); signal (SIGCHLD, child_sig_handler); for (;;) { /* main loop */ for (; child_events > 0; child_events--) { /* do event work here */ } r = pselect (n, &rd, &wr, &er, 0, &orig_sigmask); /* corps principal du programme */ } } .fi
Remarquez que l'appel pselect ci dessus peut être remplacé par :
.nf sigprocmask (SIG_BLOCK, &orig_sigmask, 0); r = select (n, &rd, &wr, &er, 0); sigprocmask (SIG_BLOCK, &sigmask, 0); .fi
mais il y a encore la possibilité qu'un signal arrive après le premier sigprocmask et avant select. si vous faites ceci, il est prudent de positionner tout au moins un timeout du durée finie de sorte que le processus ne bloque pas. Pour l'instant, la glibc fonctionne sans doute de cette manière, le noyau Linux n'ayant pas d'appel système natif pselect.
Pratique
Quelle est donc la finalité de select? Ne puis-je pas simplement lire et écrire dans les descripteurs chaque fois que je le souhaite ? L'objet de select est de surveiller de multiples descripteurs simultanément et d'endormir proprement le processus s'il n'y a pas d'activité. Il fait ceci tout en vous permettant de gérer de multiples tubes et sockets simultanément. Les programmeurs UNIX se retrouvent souvent dans une situation dans laquelle ils doivent gérer des E/S provenant de plus d'un descripteur de fichier et dans laquelle le flux de données est intermittent. Si vous deviez créer une séquence d'appels read et write, vous vous retrouveriez potentiellement bloqué sur un de vos appels attendant pour lire ou écrire des données à partir/vers un descripteur de fichier, alors qu'un autre descripteur de fichier est inutilisé bien qu'il soit disponible pour lire/écrire des données. select gère efficacement cette situation. Un exemple classique de select vient de la page de manuel de select : .nf #include <stdio.h> #include <sys/time.h> #include <sys/types.h> #include <unistd.h> int main(void) { fd_set rfds; struct timeval tv; int retval; /* Surveille stdin (fd 0) pour voir s'il a des données en entrée */ FD_ZERO(&rfds); FD_SET(0, &rfds); /* Attends jusqu'à 5 secondes. */ tv.tv_sec = 5; tv.tv_usec = 0; retval = select(1, &rfds, NULL, NULL, &tv); /* Ne pas se fier à la valeur de tv maintenant ! */ if (retval) printf("Des données sont disponibles maintenant
"); /* FD_ISSET(0, &rfds) est alors vrai. */ else printf("Aucune donnée durant les cinq secondes.
"); exit(0); } .fi
Exemple de redirection de port
Voici un exemple qui montre mieux l'utilité réelle de select. Le code ci dessous consiste en un programme de "TCP forwarding" qui redirige un port TCP vers un autre.
.nf #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <sys/time.h> #include <sys/types.h> #include <string.h> #include <signal.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <errno.h> static int forward_port; #undef max #define max(x,y) ((x) > (y) ? (x) : (y)) static int listen_socket (int listen_port) { struct sockaddr_in a; int s; int yes; if ((s = socket (AF_INET, SOCK_STREAM, 0)) < 0) { perror ("socket"); return -1; } yes = 1; if (setsockopt (s, SOL_SOCKET, SO_REUSEADDR, (char *) &yes, sizeof (yes)) < 0) { perror ("setsockopt"); close (s); return -1; } memset (&a, 0, sizeof (a)); a.sin_port = htons (listen_port); a.sin_family = AF_INET; if (bind (s, (struct sockaddr *) &a, sizeof (a)) < 0) { perror ("bind"); close (s); return -1; } printf ("accepting connections on port %d
", (int) listen_port); listen (s, 10); return s; } static int connect_socket (int connect_port, char *address) { struct sockaddr_in a; int s; if ((s = socket (AF_INET, SOCK_STREAM, 0)) < 0) { perror ("socket"); close (s); return -1; } memset (&a, 0, sizeof (a)); a.sin_port = htons (connect_port); a.sin_family = AF_INET; if (!inet_aton (address, (struct in_addr *) &a.sin_addr.s_addr)) { perror ("bad IP address format"); close (s); return -1; } if (connect (s, (struct sockaddr *) &a, sizeof (a)) < 0) { perror ("connect()"); shutdown (s, SHUT_RDWR); close (s); return -1; } return s; } #define SHUT_FD1 { if (fd1 >= 0) { shutdown (fd1, SHUT_RDWR); close (fd1); fd1 = -1; } } #define SHUT_FD2 { if (fd2 >= 0) { shutdown (fd2, SHUT_RDWR); close (fd2); fd2 = -1; } } #define BUF_SIZE 1024 int main (int argc, char **argv) { int h; int fd1 = -1, fd2 = -1; char buf1[BUF_SIZE], buf2[BUF_SIZE]; int buf1_avail, buf1_written; int buf2_avail, buf2_written; if (argc != 4) { fprintf (stderr, "Utilisation
fwd <listen-port> <forward-to-port> <forward-to-ip-address>
"); exit (1); } signal (SIGPIPE, SIG_IGN); forward_port = atoi (argv[2]); h = listen_socket (atoi (argv[1])); if (h < 0) exit (1); for (;;) { int r, n = 0; fd_set rd, wr, er; FD_ZERO (&rd); FD_ZERO (&wr); FD_ZERO (&er); FD_SET (h, &rd); n = max (n, h); if (fd1 > 0 && buf1_avail < BUF_SIZE) { FD_SET (fd1, &rd); n = max (n, fd1); } if (fd2 > 0 && buf2_avail < BUF_SIZE) { FD_SET (fd2, &rd); n = max (n, fd2); } if (fd1 > 0 && buf2_avail - buf2_written > 0) { FD_SET (fd1, &wr); n = max (n, fd1); } if (fd2 > 0 && buf1_avail - buf1_written > 0) { FD_SET (fd2, &wr); n = max (n, fd2); } if (fd1 > 0) { FD_SET (fd1, &er); n = max (n, fd1); } if (fd2 > 0) { FD_SET (fd2, &er); n = max (n, fd2); } r = select (n + 1, &rd, &wr, &er, NULL); if (r == -1 && errno == EINTR) continue; if (r < 0) { perror ("select()"); exit (1); } if (FD_ISSET (h, &rd)) { unsigned int l; struct sockaddr_in client_address; memset (&client_address, 0, l = sizeof (client_address)); r = accept (h, (struct sockaddr *) &client_address, &l); if (r < 0) { perror ("accept()"); } else { SHUT_FD1; SHUT_FD2; buf1_avail = buf1_written = 0; buf2_avail = buf2_written = 0; fd1 = r; fd2 = connect_socket (forward_port, argv[3]); if (fd2 < 0) { SHUT_FD1; } else printf ("connexion de %s
", inet_ntoa (client_address.sin_addr)); } } /* NB: lecture des données hors bande avant les lectures normales */ if (fd1 > 0) if (FD_ISSET (fd1, &er)) { char c; errno = 0; r = recv (fd1, &c, 1, MSG_OOB); if (r < 1) { SHUT_FD1; } else send (fd2, &c, 1, MSG_OOB); } if (fd2 > 0) if (FD_ISSET (fd2, &er)) { char c; errno = 0; r = recv (fd2, &c, 1, MSG_OOB); if (r < 1) { SHUT_FD1; } else send (fd1, &c, 1, MSG_OOB); } if (fd1 > 0) if (FD_ISSET (fd1, &rd)) { r = read (fd1, buf1 + buf1_avail, BUF_SIZE - buf1_avail); if (r < 1) { SHUT_FD1; } else buf1_avail += r; } if (fd2 > 0) if (FD_ISSET (fd2, &rd)) { r = read (fd2, buf2 + buf2_avail, BUF_SIZE - buf2_avail); if (r < 1) { SHUT_FD2; } else buf2_avail += r; } if (fd1 > 0) if (FD_ISSET (fd1, &wr)) { r = write (fd1, buf2 + buf2_written, buf2_avail - buf2_written); if (r < 1) { SHUT_FD1; } else buf2_written += r; } if (fd2 > 0) if (FD_ISSET (fd2, &wr)) { r = write (fd2, buf1 + buf1_written, buf1_avail - buf1_written); if (r < 1) { SHUT_FD2; } else buf1_written += r; } /* Vérifie si l'écriture de données a provoqué la lecture de données*/ if (buf1_written == buf1_avail) buf1_written = buf1_avail = 0; if (buf2_written == buf2_avail) buf2_written = buf2_avail = 0; /* une extrémité a fermé la connexion, continue d'écrire vers l'autre extrémité jusqu'à ce que ce soit vide*/ if (fd1 < 0 && buf1_avail - buf1_written == 0) { SHUT_FD2; } if (fd2 < 0 && buf2_avail - buf2_written == 0) { SHUT_FD1; } } return 0; } .fi
Le programme ci dessus redirige correctement la plupart des types de connexions TCP y compris les signaux de données hors bande OOB transmis par les serveurs telnet. Il gère le problème épineux des flux de données bidirectionnels simultanés. Vous pourriez penser qu'il est plus efficace d'utiliser un appel fork() et de dédier une tâche à chaque flux. Cela devient alors plus délicat que vous ne l'imaginez. Une autre idée est de configurer les E/S comme non bloquantes en utilisant un appel ioctl(). Cela pose également problème parce que vous finissez par avoir des timeouts inefficaces. Le programme ne gère pas plus d'une connexion à la fois bien qu'il soit aisément extensible à une telle fonctionnalité en utilisant une liste chainée de buffers - un pour chaque connexion. Pour l'instant, de nouvelles connexions provoquent l'abandon de la connexion courante.
RÈgles de select
De nombreuses personnes qui essaient d'utiliser select obtiennent un comportement difficile à comprendre et produisent des résultats non portables ou des effets de bord. Par exemple, le programme ci dessus est écrit avec précaution afin de ne bloquer nulle part, même s'il ne positionne pas du tout ses descripteurs de fichiers en mode non bloquant (voir ioctl(2)). Il est facile d'introduire des erreurs subtiles qui annuleraient l'avantage de l'utilisation de select, aussi, vais je présenter une liste de points essentiels à contrôler lors de l'utilisation de l'appel select.
1. Vous devriez toujours essayer d'utiliser select sans timeout. Votre programme ne devrait rien avoir à faire s'il n'y a pas de données disponibles. Le code dépendant de timeouts n'est en général pas portable et difficile à déboguer. |
2. La valeur n doit être calculée correctement pour des raisons d'efficacité comme expliqué plus haut. |
3. Aucun descripteur de fichier ne doit être ajouté à un quelconque ensemble si vous ne projetez pas de vérifier son état après un appel à select, et de réagir de façon adéquate. Voir la règle suivante. |
4. Après qu'un appel select a rendu la main, tous les descripteurs de fichiers de tous les ensembles doivent être vérifiés. Tout descripteur de fichier disponible pour l'écriture doit être alimenté, et tout descripteur de fichier disponible pour la lecture doit être lu, etc. |
5. Les fonctions read(), recv(), write(), et send() ne lisent ou n'écrivent pas forcément la quantité totale de données spécifiée. Si elles lisent/écrivent la quantité totale, c'est parce que vous avez une faible charge de trafic et un flux rapide. Ce n'est pas toujours le cas. Vous devriez gérer la cas où vos fonctions traitent seulement l'envoi ou la réception d'un unique octet. |
6. Ne lisez/N'écrivez jamais seulement quelques octets à la fois à moins que vous ne soyez absolument sûr de n'avoir qu'une faible quantité de données à traiter. Il est parfaitement inefficace de ne pas lire/écrire autant de données que vous pouvez en stocker à chaque fois. Les tampons de l'exemple ci dessus font 1024 octets bien qu'ils aient facilement pu être rendus aussi importants que la taille de paquet maximale sur votre réseau local. |
7. Les fonctions read(), recv(), write(), et send() tout comme l'appel select() peuvent renvoyer -1 avec errno positionné à EINTR ou EAGAIN (EWOULDBLOCK) ce qui ne relève pas de l'erreur. Ces résultats doivent être correctement gérés (cela n'est pas fait correctement ci dessus.) Si votre programme n'est pas censé recevoir de signal, alors, il est hautement improbable que vous obteniez EINTR. Si votre programme n'a pas configuré les E/S en mode non bloquant, vous n'obtiendrez pas de EAGAIN. Néanmoins, vous devriez tout de même gérer ces erreurs dans un soucis de complétude. |
8. N'appelez jamais read(), recv(), write(), ou send() avec un buffer de taille nulle |
9. A l'exception des cas indiqués en 7., les fonctions read(), recv(), write(), et send() n'ont jamais une valeur de retour inférieure à 1 sauf si une erreur est survenue. Par exemple, un read() sur un tube dont l'extrémité est morte renvoie zéro (de même qu'une erreur de fin de fichier), mais ne renvoie zéro qu'une seule fois. Dans le cas où l'une de ces fonctions renvoie 0 ou -1, vous ne devriez pas utiliser ce descripteur à nouveau. Dans l'exemple ci dessus, je ferme le descripteur immédiatement, et ensuite, je le positionne à -1 afin qu'il ne soit pas inclus dans un ensemble. |
10. La valeur de timeout doit être initialisée à chaque nouvel appel à select, puisque des systèmes d'exploitation modifient la structure. Cependant, pselect ne modifie pas sa structure de timeout. |
11. J'ai entendu que le niveau socket Windows ne traite pas correctement les données hors bande (OOB). Il ne gère pas non plus les appels select lorsqu'aucun descripteur de fichier n'est positionné. N'avoir aucun descripteur de fichier positionné est un moyen utile afin d'endormir le processus avec une précision inférieure à la seconde en utilisant le timeout. (Voir plus loin.) |
Émulation de usleep
Sur les systèmes qui ne possèdent pas la fonction usleep, vous pouvez appeler select avec un timeout à valeur finie et sans descripteur de fichier de la façon suivante :
.nf struct timeval tv; tv.tv_sec = 0; tv.tv_usec = 200000; /* 0.2 secondes */ select (0, NULL, NULL, NULL, &tv); .fi
Le fonctionnement n'est cependant garanti que sur les systèmes Unix.
Valeur renvoyée
En cas de succès, select renvoie le nombre total de descripteurs de fichiers encore présents dans les ensembles de descripteurs de fichiers. En cas de timeout échu, alors les descripteurs de fichiers devraient tous être vides (mais peuvent ne pas l'être sur certains systèmes). par contre, la valeur renvoyée est clairement zéro. Une valeur de retour égale à -1 indique une erreur, errno est alors positionné de façon adéquate. En cas d'erreur, les ensembles renvoyés et le contenu de la structure de timeout sont indéfinis et ne devraient pas être exploités. pselect ne modifie cependant jamais ntimeout.
Erreurs
EBADF Un ensemble contenait un descripteur de fichier invalide. Cette erreur se produit fréquemment lorsque l'on ajoute à un ensemble un descripteur de fichier qui a déjà été fermé avec un appel close, ou lorsque ce descripteur de fichier a déjà accusé une erreur. Ainsi, devriez vous cesser d'ajouter aux ensembles tout descripteur de fichier qui renvoie une erreur de lecture ou d'écriture. |
EINTR Un signal interrompant l'appel a été intercepté, par exemple un signal SIGINT ou SIGCHLD etc. Dans un tel cas, vous devriez rétablir vos ensembles de descripteurs de fichiers et réessayer. |
EINVAL Est renvoyé si n a une valeur négative. |
ENOMEM Echec d'allocation de mémoire interne. |
Notes
De façon générale, tous les systèmes d'exploitation qui gèrent les sockets, implantent également select. Certaines personnes considèrent select comme une fonction ésotérique et rarement utilisée. En fait, de nombreux types de programmes deviennent extrêmement compliqués sans cette fonction. select peut être utilisé pour résoudre de façon portable et efficace de nombreux problèmes que des programmeurs naïfs essaient de résoudre avec des threads, des forks, des IPCs, des signaux, des mémoires partagées et d'autres méthodes peu élégantes. pselect est une fonction plus récente qui est moins répandue.
L'appel-système poll (2) a les mêmes fonctionnalités que select, avec un comportement un peu moins subtil.Il est moins portable que select.
Conformité
BSD4.4(la fonction select est tout d'abord apparue dans BSD4.2). Généralement portable de/vers des systèmes non BSD possédant un équivalent au niveau socket BSD (y compris les variantes système V). Néanmoins, notez bien que la variante système V positionne typiquement la variable timeout avant de rendre la main alors que la variante BSD ne le fait pas.
La fonction pselect est définie dans le standard IEEE 1003.1g-2000 (POSIX.1g). On la trouve dans la glibc 2.1 et les versions suivantes. La Glibc 2.0 possède une fonction portant ce nom mais qui n'a pas de pas de paramètre sigmask .
Voir aussi
accept (2), connect (2), ioctl (2), poll (2), read (2), recv (2), select (2), send (2), sigaddset (3), sigdelset (3), sigemptyset (3), sigfillset (3), sigismember (3), sigprocmask (2), write (2)
Auteurs
Cette page de manuel a été rédigée par Paul Sheer.
Traduction
Stéphan Rafin, 2002 Christophe Blaess, 2003.
Poster un commentaire