Leçon 18 : Non-blocking I/O et epoll
Blocking I/O est le comportement par défaut — read() attend que des données arrivent. Avec O_NONBLOCK, read() retourne immédiatement avec EAGAIN si aucune donnée n'est prête. Mais comment gérer des milliers de FDs simultanément ? epoll résout exactement ce problème — une event loop qui nous notifie
Blocking I/O, c'est faire la queue pour un billet et attendre. Non-blocking, c'est dire au guichetier « appelle-moi quand ce sera prêt ». epoll, c'est un standardiste qui gère des milliers d'appels et ne te transfère que ceux qui attendent ta réponse.
- non-blocking I/O
- Mode dans lequel les appels I/O (read, write, accept) ne bloquent pas. Si aucune donnée n'est prête, ils retournent -1 avec errno=EAGAIN/EWOULDBLOCK. Activé avec le flag O_NONBLOCK.
- epoll
- Interface Linux pour surveiller les événements I/O sur un grand ensemble de descripteurs de fichiers. Se compose de epoll_create, epoll_ctl et epoll_wait. Ne retourne que les FDs prêts — O(1) contre O(n) pour select.
- edge-triggered (ET)
- Mode epoll dans lequel un événement n'est signalé qu'une seule fois — quand le FD passe de non-prêt à prêt. Nécessite de lire jusqu'à EAGAIN à chaque fois. Plus efficace mais plus complexe.
- level-triggered (LT)
- Mode epoll par défaut — l'événement est signalé à chaque appel de epoll_wait tant que le FD est encore prêt. Plus simple que ET mais peut provoquer un busy-loop si mal géré.
- event loop
- Un pattern de programmation où un programme attend des événements et les traite un par un — une boucle infinie qui appelle epoll_wait et déclenche des callbacks. Le cœur de Node.js, Nginx et Triton.