Ce n’est pas la technique secrète de Gérard Depardieu pour finir ses plats, ni le coup spécial du cavalier aux échecs. Le coup de la fourchette est la stratégie employée par les serveurs pour répondre aux sollicitations des clients, dans le monde informatique. Ne cherchez pas sur Internet, vous ne le trouverez pas présenté ainsi. Pourtant, il en est à la base de tout service correctement écrit.
Mais reprenons l’analogie du postier. Si un client s’adresse toujours à son bureau de poste, le postier voit défiler plusieurs clients dans la journée. Il existe 2 stratégies pour accueillir et répondre au besoin des clients. La première est bien connue de nos administrations : il s’agit de la file d’attente. Si 2 clients arrivent en même temps devant le bureau de poste, le postier traitera d’abord le premier arrivé.
Si le premier client est rapide, le second client n’attendra pas très longtemps pour effectuer à son tour ses démarches. Avec des ‘si’ … beaucoup de choses sont possibles. Mais, dans la réalité, les choses ne se passent pas toujours comme on veut. Le client peut ne pas être très réactif, un événement peut le distraire, … Et de l’autre côté du guichet, le postier attend la suite de la procédure.
Une solution serait d’augmenter les effectifs du bureau de poste. En plus des postiers, il faut aussi un rôle d’hôte d’accueil pour rediriger les clients au guichet qui semble le moins engorgé. Mais les ressources financières du service de Poste ne sont pas infinies. Et employer plusieurs postiers même lorsqu’il n’y a pas d’activité, c’est gâcher des ressources. Capitaliste dites-vous ?
Pour limiter la facture lors du traitement d’une demande client, l’idée est de n’avoir qu’un seul postier qui sert aussi d’hôte d’accueil. Lorsqu’un client se présente, le postier se clone. Dans le monde réel, ce n’est pas possible, mais en informatique, cela tient à une commande : fork ou fourchette en français. Le processus crée un clone qui traite la demande client et lui reste à l’accueil.
Ainsi, si 100 clients se présentent en même temps au bureau de Poste, le postier réalise un Kage Bunshin No Jutsu et traite les demandes en parallèle. Une fois le traitement réalisé, le clone en informe le postier original et disparaît en libérant les ressources qu’il utilisait pour traiter la demande du client. Avec cette stratégie, aucun client ne patiente des heures parce que le client précédent ne retrouve plus son portefeuille.
Cette stratégie n’est pas sans conséquence. Le bureau de Poste n’a pas des capacités d’accueil infinies. Sauf s’il s’agit d’un ‘sans serveur’, il sait qu’il est limité par des contraintes physiques. Et en cas de forte affluence, les postiers se retrouveront ralentis. Une règle est donc ajoutée au postier original (l’hôte d’accueil), s’il dépasse un certain nombre de clones actifs, alors, il refusera toute nouvelle demande.
Le postier est un processus qui exécute un programme. Ce programme peut être exécuté en parallèle par d’autres processus. Le fork est la stratégie la plus simple et la plus efficace lorsqu’on doit programmer le comportement d’un serveur. Le fork est aussi une porte d’entrée dans le multitâche et la programmation en ‘temps réel’. Mais il présente une faiblesse. Le clone créé utilise autant de ressources que l’original.
Mal maîtrisé, un fork peut se révéler lourd pour le système. Dans les mains d’un mauvais programmeur, cette commande peut faire écrouler la machine sur laquelle il est utilisé. Il existe donc une alternative plus légère nommée Thread (se prononce Fred en français). L’idée reste la même. Seule la partie nécessaire du programme est matérialisée. Mais ce sera une autre histoire.
Au début de mon article, je dis que le coup de la fourchette est à la base de tout service informatique bien conçu. C’est vrai. Et en informatique, tout peut être vu comme ‘service’. Dernière remarque, fork peut aussi se traduire par ‘embranchement’ ou ‘bifurcation’, et le programme parcourt en parallèle tous les chemins.