E/S bloquantes ou non bloquantes

Un appel système bloquant suspend le thread appelant jusqu'à ce que l'opération puisse continuer. Lorsque vous appelez recv() sur une socket sans données, le noyau met votre thread en attente jusqu'à l'arrivée des octets.

C'est simple à comprendre : une connexion, un thread, un code exécuté en ligne droite. Le coût apparaît lorsque vous devez servir des milliers de clients simultanément.

Avec les entrées-sorties bloquantes, un client bloqué immobilise tout le thread. La solution classique consiste à utiliser un thread — ou un processus — par connexion.

Cela fonctionne jusqu'à un certain point, mais 10 000 threads signifient 10 000 piles, de nombreux changements de contexte et une surcharge du planificateur. C'est le célèbre problème C10k, qui a incité les serveurs à adopter des architectures pilotées par les événements.

Une socket non bloquante ne se met jamais en sommeil. Si un appel ne peut pas se terminer immédiatement, il renvoie aussitôt -1 et définit errno sur EAGAIN ou EWOULDBLOCK.

Votre code doit alors réessayer plus tard. Un seul thread peut ainsi gérer de nombreuses sockets sans jamais rester bloqué sur l'une d'elles.

Vous rendez un descripteur non bloquant en ajoutant l'indicateur O_NONBLOCK avec fcntl(). Lisez toujours d'abord les indicateurs actuels, puis combinez-les avec OR et le bit voulu, afin de ne pas écraser les autres réglages.

Ce même utilitaire s'utilise aussi bien avec les sockets d'écoute, les sockets clientes acceptées qu'avec les tubes.

Les entrées-sorties non bloquantes rendent les opérations partielles normales. Un appel recv() peut renvoyer moins d'octets que demandé, et send() peut n'accepter qu'une partie de votre tampon.

Vous devez suivre la quantité déjà envoyée ou reçue et reprendre à partir de là. Ne supposez jamais qu'un seul appel transfère tous les octets.

La manière naïve d'utiliser des sockets non bloquantes consiste à parcourir toutes les sockets en réessayant constamment. Cette attente active consomme 100 % du CPU même lorsqu'il ne se passe rien.

Ce que nous voulons vraiment, c'est demander au noyau : « indiquez-moi quels descripteurs sont prêts et laissez-moi dormir jusque-là ». C'est exactement ce que fournit la notification de disponibilité.

Le multiplexage des entrées-sorties permet à un thread d'attendre simultanément de nombreux descripteurs et de se réveiller dès qu'au moins l'un d'eux est prêt. Le noyau se charge de la surveillance.

Les interfaces classiques sont select() et poll(). Elles fonctionnent, mais rescannent chaque descripteur à chaque appel, ce qui devient coûteux à grande échelle.

select() et poll() sont tous deux en O(n) : chaque appel transmet l'ensemble des descripteurs au noyau, qui les parcourt tous, puis vous les parcourez encore pour trouver ceux qui sont prêts.

select() est également limité par FD_SETSIZE (souvent 1024). Pour des milliers de connexions, cette surcharge devient prédominante.

epoll est la solution évolutive de Linux. Vous enregistrez une fois votre intérêt pour un descripteur, puis le noyau conserve une structure de données interne qui suit leur disponibilité.

Chaque attente ne renvoie que les descripteurs réellement prêts ; le coût dépend donc des connexions actives, et non du nombre total de connexions. Il est ainsi approximativement en O(1) par événement prêt.

epoll et les sockets non bloquantes forment une équipe. epoll vous indique qu'un descripteur est prêt ; les appels non bloquants vous permettent de le vider sans jamais vous mettre en sommeil.

Vous devez toujours définir O_NONBLOCK sur les sockets transmises à epoll. Sinon, un réveil intempestif ou une lecture partielle pourrait bloquer votre thread unique de boucle d'événements.

Imaginez le serveur comme une boucle : bloquez dans epoll_wait(), récupérez une courte liste de descripteurs prêts, effectuez un traitement non bloquant sur chacun, puis recommencez.

Le thread dort lorsqu'il n'y a rien à faire et ne se réveille que pour du travail réel. Un seul thread peut maintenant servir efficacement des dizaines de milliers de connexions.

Vérifiez votre compréhension des sockets non bloquantes.

Les entrées-sorties bloquantes sont simples, mais mobilisent un thread par connexion, ce qui ne passe pas à l'échelle. Les entrées-sorties non bloquantes renvoient immédiatement EAGAIN au lieu de mettre le thread en sommeil.

Interroger les sockets en boucle serrée gaspille le CPU ; nous utilisons donc la notification de disponibilité. select/poll sont en O(n), tandis que epoll peut gérer plusieurs milliers de connexions. Nous allons maintenant configurer epoll.