Man page 2 : select_tut

• readfds
      Cet ensemble est examiné afin de déterminer si des données sont disponibles en lecture à partir d'un de ses descripteurs de fichier. 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.
• 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 fichier. 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.
• exceptfds
      Cet ensemble est examiné pour des « conditions exceptionnelles ». En pratique, seule une condition exceptionnelle est courante : la disponibilité de données hors-bande (OOB : Out Of Band) en lecture sur une socket TCP. Consultez recv(2), send(2) et tcp(7) pour plus de détails sur les données hors bande. Un autre cas moins courant dans lequel select(2) indique une condition exceptionnelle survient avec des pseudoterminaux en mode paquet ; consultez tty_ioctl(4).) Suite à un appel à select(), exceptfds ne contient plus aucun de ses descripteurs de fichier à l'exception de ceux pour lesquels une condition exceptionnelle est survenue.
• nfds
      Il s'agit d'un entier valant un de plus que n'importe lequel des descripteurs de fichier de tous les ensembles. En d'autres termes, lorsque vous ajoutez des descripteurs de fichier à chacun des ensembles, vous devez déterminer la valeur entière maximale de tous ces derniers, puis ajouter un à cette valeur, et la passer comme paramètre nfds.
• utimeout
      Il s'agit du temps le plus long que select() pourrait attendre avant de rendre la main, même si rien d'intéressant n'est arrivé. Si cette valeur est positionnée à NULL, alors, select() bloque indéfiniment dans l'attente qu'un descripteur de fichier devienne prêt. utimeout peut être positionné à zéro seconde, ce qui provoque le retour immédiat de select(), en indiquant quels descripteurs de fichiers étaient prêts au moment de l'appel. La structure struct timeval est définie comme :

struct timeval {
    time_t tv_sec;    /* secondes */
    long tv_usec;     /* microsecondes */
};

• ntimeout
      Ce paramètre de pselect() a la même signification que utimeout, mais struct timespec a une précision à la nanoseconde comme explicité ci-dessous :

struct timespec {
    long tv_sec;    /* secondes */
    long tv_nsec;   /* nanosecondes */
};

• sigmask
      Cet argument renferme un ensemble de signaux que le noyau doit débloquer (c'est-à-dire supprimer du masque de signaux du thread appelant) pendant que l'appelant est bloqué par pselect() (consultez 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. Dans ce cas, pselect() se comporte alors de façon identique à select().

pselect() est utile si vous attendez un signal ou qu'un descripteur de fichier deviennent prêt pour des entrées-sorties. Les programmes qui reçoivent des signaux utilisent généralement le gestionnaire de signal uniquement pour lever un drapeau global. Le drapeau global indique que l'événement doit être traité 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éfinir le masque des signaux qui sont censés être reçus que 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(2). Notre appel pselect() débloquerait SIGCHLD en utilisant le masque de signaux vide. Le programme ressemblerait à ceci :

static volatile sig_atomic_t got_SIGCHLD = 0;
static void
child_sig_handler(int sig)
{
    got_SIGCHLD = 1;
}
int
main(int argc, char *argv[])
{
    sigset_t sigmask, empty_mask;
    struct sigaction sa;
    fd_set readfds, writefds, exceptfds;
    int r;
    sigemptyset(&sigmask);
    sigaddset(&sigmask, SIGCHLD);
    if (sigprocmask(SIG_BLOCK, &sigmask, NULL) == -1) {
        perror("sigprocmask");
        exit(EXIT_FAILURE);
    }
    sa.sa_flags = 0;
    sa.sa_handler = child_sig_handler;
    sigemptyset(&sa.sa_mask);
    if (sigaction(SIGCHLD, &sa, NULL) == -1) {
        perror("sigaction");
        exit(EXIT_FAILURE);
    }
    sigemptyset(&empty_mask);
    for (;;) {          /* main loop */
        /* Initialiser readfds, writefds et exceptfds
           avant l'appel à pselect(). (Code omis.) */
        r = pselect(nfds, &readfds, &writefds, &exceptfds,
                    NULL, &empty_mask);
        if (r == -1 && errno != EINTR) {
            /* Gérer les erreurs */
        }
        if (got_SIGCHLD) {
            got_SIGCHLD = 0;
            /* Gérer les événements signalés ici; e.g., wait() pour
               que tous les fils se terminent. (Code omis.) */
        }
        /* corps principal du programme */
    }
}

Quelle est donc la finalité de select() ? Ne peut on pas simplement lire et écrire dans les descripteurs chaque fois qu'on 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é. Les programmeurs UNIX se retrouvent souvent dans une situation dans laquelle ils doivent gérer des entrées-sorties 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(2) et write(2), 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 prêt pour des entrées-sorties. select() gère efficacement cette situation.

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 ses descripteurs de fichier en mode non bloquant.Il est facile d'introduire des erreurs subtiles qui annuleraient l'avantage de l'utilisation de select(), aussi, voici une liste de points essentiels à contrôler lors de l'utilisation de 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 nfds 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 le retour de select(), tous les descripteurs de fichier dans tous les ensembles devraient être testés pour savoir s'ils sont prêts.
• 5.
      Les fonctions read(2), recv(2), write(2) et send(2) 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 le 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-dessous font 1024 octets bien qu'ils aient facilement pu être rendus plus grands.
• 7. Les fonctions read(2), recv(2), write(2) et send(2) tout comme l'appel select() peuvent renvoyer -1 avec errno positionné à EINTR ou EAGAIN (EWOULDBLOCK) ce qui ne relève pas d'une 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 entrées-sorties en mode non bloquant, vous n'obtiendrez pas de EAGAIN.
• 8.
      N'appelez jamais read(2), recv(2), write(2) ou send(2) avec un tampon de taille nulle.
• 9.
      Si l'une des fonctions read(2), recv(2), write(2) et send(2) échoue avec une erreur autre que celles indiquées en 7., ou si l'une des fonctions d'entrée renvoie 0, indiquant une fin de fichier, vous ne devriez pas utiliser ce descripteur à nouveau pour un appel à select(). Dans l'exemple ci-dessous, le descripteur est immédiatement fermé et ensuite est positionné à -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. Comme select() modifie ses ensembles de descripteurs de fichiers, si l'appel est effectué dans une boucle alors les ensembles doivent être réinitialisés avant chaque appel.

Sur les systèmes qui ne possèdent pas la fonction usleep(3), vous pouvez appeler select() avec un timeout à valeur finie et sans descripteur de fichier de la façon suivante :

   struct timeval tv;
    tv.tv_sec = 0;
    tv.tv_usec = 200000;  /* 0.2 secondes */
    select(0, NULL, NULL, NULL, &tv);

Le fonctionnement n'est cependant garanti que sur les systèmes UNIX.