Et cette « boucle d'évènement » unique, elle s'appelle... ton noyau. Démultiplexer des « requêtes » selon un sélecteur donné, c'est ce que fait le noyau quand il répartit les paquets reçus du réseau selon l'adresse et le port de destination du paquet (oui, je me suis placé à un niveau « en dessous »). orcément, quand tu as oublié qu'il existait autre chose que le Web et le port 80, ça peut faire bizarre comme sensation.
Je décris justement que les systèmes d'exploitation de type unix ont déjà implémenté pour toi tout ça (c'est la première partie de mon billet). L'article de Christophe Blaess est vraiment bien sur le sujet.
Il n'y a pas que le monde tcp/udp (comme les fichiers par exemple) et ça tombe bien ce que les SE implémente permet aussi de les gérer (cf: titre de la première partie ;) ).
Moui... tu viens de décrire l’ordonnanceur du noyau, quoi, qui répartit les tâches entre différents processus représentant différentes applications qui écoutent sur des ports différents, non ?
Non pas vraiment. Il s'agit ici d'avoir une granularité assez fine pour faire un switch non pas sur les threads (ce qui est plutôt lourd), mais au sein d'un même thread.
En fait, la manie du tout-Web a amené de gros anciens SPOF sous forme dispatchers de requêtes HTTP.
Et c'est toi qui parle que de TCP ? ;) L'accès aux fichiers ou à certains périphériques entre très bien dans ce modèle (je parle d'IO tout le long pas de HTTP).
Sans parler de comment tu gères ta file quand elle est pleine, parce que le tail-drop ça fait plus de 20 ans qu'on sait que c'est mauvais.
J'ai pas retrouvé rapidement de sources, mais je sais que vertx fait très gaffe à ça. Il fait attention à s'appuyer sur le SE pour gérer la congestion TCP par exemple. Tu peux aussi, pour d'autres besoins, utiliser Rx et sa gestion de la backpressure.
[^] # Re: Petit joueur
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 2. Dernière modification le 07 mars 2018 à 16:02.
Je décris justement que les systèmes d'exploitation de type unix ont déjà implémenté pour toi tout ça (c'est la première partie de mon billet). L'article de Christophe Blaess est vraiment bien sur le sujet.
Il n'y a pas que le monde tcp/udp (comme les fichiers par exemple) et ça tombe bien ce que les SE implémente permet aussi de les gérer (cf: titre de la première partie ;) ).
Non pas vraiment. Il s'agit ici d'avoir une granularité assez fine pour faire un switch non pas sur les threads (ce qui est plutôt lourd), mais au sein d'un même thread.
Et c'est toi qui parle que de TCP ? ;) L'accès aux fichiers ou à certains périphériques entre très bien dans ce modèle (je parle d'IO tout le long pas de HTTP).
J'ai pas retrouvé rapidement de sources, mais je sais que vertx fait très gaffe à ça. Il fait attention à s'appuyer sur le SE pour gérer la congestion TCP par exemple. Tu peux aussi, pour d'autres besoins, utiliser Rx et sa gestion de la backpressure.