Nous travaillons sur le programme prog01_interaction.cpp.
Ce programme illustrera le fait que la communication minimale qui soit immédiatement envisageable repose sur les informations de la ligne de commande ainsi que sur les entrées/sorties standards.

Ce tout premier programme permet essentiellement de se familiariser avec l'environnement de travail.
La commande $ make ↵ lancée depuis un terminal ouvert dans le répertoire de travail contenant ces fichiers, provoque la compilation de tous les programmes de la séance✍.

Pour exécuter un tel programme il suffit de saisir son nom et ses éventuels arguments sur la ligne de commande du même terminal $ ./prog01_interaction ceci 12 cela 34 hello ↵ Pour l'instant, vous devez observer le comportement de ce programme en étudiant attentivement son code source.

Tout d'abord, intéressons nous à la ligne de commandes : Invoquez le programme avec diverses lignes de commande afin de vous assurer de votre bonne compréhension.

Concernant l'affichage des messages, nous utilisons ici un procédé peu conventionnel.
En effet, il est courant d'avoir recours à des fonctionnalités d'assez haut niveau (println!() en Rust, printf() en langage C,

std::cout << ... 

en C++, print() en Python...) afin de bénéficier de confort pour ces opérations très courantes.
Seulement, toutes ces fonctionnalités de haut niveau reposent au bout du compte sur des fonctionnalités de bas niveau fournies par le système d'exploitation, et ce sont justement ces moyens de communication élémentaires des systèmes d'exploitation qui représentent une partie conséquente du sujet d'étude de ce module d'enseignement.
Nous nous efforçons d'utiliser ici ces mécanismes de bas niveau afin d'illustrer leurs principes généraux et les similarités avec d'autres moyens de communication.
Ce choix a été fait uniquement pour des raisons pédagogiques ; cela ne signifie pas que c'est la bonne façon de faire en général, quel que soit le contexte applicatif, bien au contraire !

Tout ce qui concerne le formatage des chaînes de caractères est traité par la fonction utilitaire crs::txt().
Son utilisation est triviale : son premier paramètre est une chaîne littérale dont chaque symbole '%' est remplacé par la valeur d'un des paramètres suivants (dans l'ordre).
Le résultat est une chaîne C++ std::string.
La manière de constituer une telle chaîne de caractères n'est absolument pas liée aux principes de fonctionnement des moyens de communication offerts par le système d'exploitation ; il ne s'agit que de “calculs” pour transformer des données applicatives en une séquence d'octets que les être humains interprètent comme du texte.

L'écriture effective, vers le terminal, du message ainsi constitué a lieu avec la fonction crs::writeAll() qui attend en premier paramètre un descripteur de fichier.
Un tel descripteur de fichier est une notion fondamentale en communication.
Il s'agit d'un entier pour désigner un “tuyau” de communication par son numéro.
Par défaut, tout processus dispose de trois descripteurs de fichier déjà ouverts, les entrées/sorties standards : La distinction STDOUT_FILENO/STDERR_FILENO n'est pas immédiate puisque tous ces messages aboutissent dans le terminal ; comme nous le verrons plus tard, il est possible de rediriger ces descripteurs afin qu'ils produisent leur effet sur des ressources distinctes.
Ici, nous envoyons tous les caractères✍ d'une chaîne C++ préalablement constituée vers le descripteur de fichier numéro 1, STDOUT_FILENO, la sortie standard, qui produit par défaut son affichage dans le terminal.

La fonction utilitaire crs::extract() est, tout comme crs::txt(), une fonctionnalité de “calcul” qui analyse une chaîne de caractères fournie (le premier paramètre) pour en extraire des valeurs ayant du sens dans l'application (la succession de paramètres suivants, un seul sur cet exemple)✍ ; elle n'est pas liée aux principes de fonctionnement des moyens de communication offerts par le système d'exploitation.
Le résultat de cette fonction utilitaire est un entier indiquant le nombre de valeurs extraites avec succès (une seule était attendue sur cet exemple).

De la même façon, nous constatons que, dans la deuxième partie du code source fourni, la saisie au clavier a lieu par l'appel à la fonction utilitaire crs::readLine() sur le descripteur de fichier numéro 0, STDIN_FILENO, l'entrée standard.
Cette fonction invoque l'appel système read() jusqu'à obtenir le caractère de retour à la ligne '\n' et nous renvoie la chaîne C++ ainsi constituée.

Vous remarquerez certainement que la boucle de saisie doit s'interrompre lorsque la fin-de-fichier (EOF) est atteinte ; dans ce cas, l'appel système read() renvoie 0 pour indiquer qu'il n'y a plus rien à lire et notre fonction crs::readLine() fournit une chaîne vide.
Seulement, même s'il s'abstient d'utiliser le clavier quelques temps, tant que l'utilisateur est vivant il peut à tout moment décider de reprendre sa saisie.
Pour cette raison, il est possible de simuler la fin-de-fichier (EOF) en saisissant la combinaison de touches Ctrl d sur une ligne vide dans le terminal afin de signaler l'intention de terminer la saisie.
Vous devriez alors constater la détection de cet événement par le programme et la sortie de la boucle.

En vous inspirant du code déjà écrit, vous pourrez compléter le code fourni selon les commentaires indiqués.
Ceci vous permettra de réaliser un premier programme interactif qui réagit simplement à vos sollicitations.

Les éléments décrits, constatés et réalisés ici ont un intérêt pratique très limité en l'état mais servent de base pour la démarche à suivre dans les futurs exercices de cette séance et des suivantes.

Documentation utile :

Nous travaillons sur le programme prog02_copy.cpp.
Ce programme nous montrera que l'usage des différents descripteurs de fichier est similaire, quelles que soient les ressources désignées.

Ce programme propose de recopier des données entre différents fichiers ; il s'agit de lire les données de l'un (entrée) pour les placer dans l'autre (sortie).
Puisque les fichiers et les entrées/sorties standards (entre autres) sont manipulés à travers la même notion de descripteur de fichier, ces opérations de recopies peuvent avoir lieu indifféremment des uns vers les autres.

Le programme fourni analyse sa ligne de commande pour y détecter d'éventuels noms de fichier à utiliser en entrée (-i) ou en sortie (-o) pour la recopie.
Si aucun nom de fichier n'est donné pour l'entrée, c'est l'entrée standard qui sera utilisée, et si aucun nom de fichier n'est donné pour la sortie, c'est la sortie standard qui sera utilisée.

En complétant les points

{1}

et

{2}

du programme fourni, vous réaliserez l'ouverture de ces fichiers lorsqu'ils sont requis.

Dès qu'on accède à des ressources du système (ici les fichiers), il convient de se poser la question de la libération de ces ressources.
En complétant les points

{3}

et

{4}

du programme fourni, vous fermerez ces fichiers lorsqu'ils ne seront plus utiles (à la fin du programme).

La partie active du programme est constituée de la boucle de recopie.
Il s'agit, à chaque itération, d'extraire du fichier d'entrée une quantité d'octets quelconque mais qui tienne dans la tampon mémoire buffer, puis de transférer exactement la quantité d'octets obtenue de la mémoire tampon buffer vers le fichier de sortie.
Ceci doit être réalisé au point

{5}

du programme fourni.
L'opération de lecture utilise la variante de crs::read() à trois paramètres (comme l'appel système read()) : Le résultat de cette opération de lecture est un entier qui indique la quantité d'octets effectivement obtenus dans buffer : L'opération d'écriture utilise la variante de crs::writeAll() à trois arguments (qui utilise l'appel système write()) : Le résultat de cette opération d'écriture est un entier qui indique la quantité d'octets effectivement transférés : Globalement, cette boucle de lecture/écriture se répète jusqu'à ce que la fin-de-fichier (EOF) soit détectée lors de la lecture, c'est à dire lorsque crs::read() renvoie 0.
Cette démarche de recopie est un grand classique de la communication :

Pour tester ce programme, nous le lançons dans un premier temps sans argument $ ./prog02_copy ↵ Il doit alors se contenter de répéter dans le terminal ce que nous saisissons au clavier.
Ainsi, nous voyons apparaître nos lignes de texte en double : une fois lors de la saisie, une seconde fois lors de la recopie.
Vérifiez que la saisie de la combinaison de touches Ctrl d sur une ligne vide provoque bien la détection de la fin-de-fichier et la sortie de la boucle de recopie (donc du programme).

Vous pouvez alors tester la lecture d'un fichier en entrée $ ./prog02_copy -i GNUmakefile ↵ Vous devez constater que le contenu du fichier apparaît dans le terminal.

Vous pouvez également tester l'écriture dans un fichier de sortie $ ./prog02_copy -o output_file ↵ Tout ce que vous saisissez au clavier est inscrit dans ce fichier.
Après la fin de la saisie (Ctrl d) vous devriez constater que le fichier output_file✍ contient bien les lignes de texte que vous avez entrées au clavier.

La dernière combinaison revient à faire une copie d'un fichier vers un autre $ ./prog02_copy -i GNUmakefile -o output_file ↵ Vous devriez constater que le fichier output_file a bien un contenu identique à celui du fichier GNUmakefile.

Pour faciliter l'expérimentation nous n'avons manipulé ici que des données textuelles mais notre programme ne suppose en aucune façon qu'il a affaire à du texte ; il recopie des paquets d'octets sans chercher à les interpréter et le texte n'est qu'un cas particulier.
Vous pouvez par exemple recopier un programme exécutable $ ./prog02_copy -i prog01_interaction -o output_file ↵ La commande $ diff prog01_interaction output_file ↵ vous indiquera si ces deux fichiers sont différents.
S'ils sont identiques, vous pouvez rendre la copie exécutable et l'utiliser $ chmod +x output_file ↵ $ ./output_file a 1 bc 23 def ↵

À travers ces quelques essais vous avez vérifié quelques propriétés des entrées/sorties et des fichiers : Maintenant que cette notion a été mise en évidence, nous utiliserons dans les prochains exercices crs::out(...) et crs::err(...) en lieu et place de crs::writeAll(STDOUT_FILENO, crs::txt(...)) et crs::writeAll(STDERR_FILENO, crs::txt(...)) afin de faciliter la rédaction et la relecture du code source.

Documentation utile :

Nous travaillons sur le programme prog03_fork_waitpid.cpp.
Ce programme nous montrera qu'un processus peut en engendrer un autre ; il doit obligatoirement attendre la fin de l'exécution du processus enfant ce qui permet de connaître les circonstances de sa terminaison.

En exécutant tout d'abord le programme fourni sans l'avoir encore complété, vous constaterez qu'un processus est désigné de manière unique dans le système d'exploitation par un numéro : le PID (process-identifier) qui est consulté avec l'appel système getpid().
Chaque processus a un et un seul processus parent dont l'identifiant est fourni par l'appel système getppid()✍.

En complétant le point

{1}

du programme fourni, vous utiliserez l'appel système fork() qui permet de faire apparaître un nouveau processus.
Ce procédé se déroule comme ceci : Nous pouvons interpréter la création d'un nouveau processus comme la métaphore de la photocopie d'une feuille de papier :

À la sortie de fork(), la seule distinction entre les deux processus est visible à travers la valeur de retour de cet appel.
Relancez alors le programme afin de contrôler avec attention les messages obtenus et notamment la relation entre le résultat de l'appel crs::fork() et les identifiants des processus.
Le processus enfant obtient 0 alors que le processus initial obtient l'identifiant du processus enfant qu'il vient de créer✍.

Maintenant que vous savez distinguer le processus initial du processus enfant qu'il vient de créer, vous pouvez compléter le point

{2}

du code fourni afin que ces deux processus se comportent différemment.
Le point

{3}

, qui n'est exécuté que par le processus initial, doit également être complété pour réaliser l'opération d'attente du processus enfant.

Relancez à nouveau le programme en contrôlant attentivement l'enchaînement des messages.
Vous devez constater que l'opération d'attente bloque le processus initial jusqu'à ce que le processus enfant ait terminé son exécution.
L'opération d'attente permet également de connaître les circonstances de la terminaison du processus enfant.
En l'état, le processus enfant quitte le bloc de code associé à l'instruction if puis atteint la fin de la fonction main() en affichant un message puis en renvoyant la valeur 0.
Vérifiez que la variable status renseignée lors de l'attente obtient bien cette valeur.

En intervenant sur le point

{4}

du programme fourni, vous provoquerez une terminaison volontaire (et normale) du processus enfant en renvoyant une valeur entière de votre choix par l'appel exit()✍.
La transmission d'une telle valeur est un mécanisme simple pour indiquer comment s'est terminé un programme ; généralement 0 signifie que tout s'est bien déroulé✍.
Relancez alors le programme afin de vérifier que la variable status obtient bien la valeur que vous avez choisie.

Il se peut également qu'un processus ne se termine pas de manière volontaire ; c'est le cas en particulier des “plantages”.
Dans ces conditions, le système d'exploitation envoie un signal au processus incriminé afin de provoquer sa terminaison brutale.
La valeur obtenue par status n'a alors aucun sens puisque le processus enfant n'a pas eu l'occasion de renvoyer explicitement sa valeur !
C'est ici que la variable signal, également renseignée lors de l'opération d'attente du processus enfant, intervient pour nous faire connaître le signal qui a provoqué la terminaison brutale du processus enfant.
En complétant le point

{5}

du programme fourni, vous provoquerez un tel plantage.
Relancez à nouveau le programme pour constater l'information obtenue par la variable signal.

À travers ces quelques essais vous avez réalisé la démarche usuelle pour utiliser un nouveau processus :

Documentation utile :

Nous travaillons sur le programme prog04_address_space.cpp.
Ce programme nous montrera qu'un processus et son parent ont initialement des espaces d'adressages virtuels identiques mais distincts.
Si une zone mémoire physiquement commune est nécessaire pour échanger des données entre ces deux processus, elle doit être explicitement demandée au système d'exploitation.

Il s'agit dans un premier temps d'exécuter le programme fourni sans l'avoir encore complété, et d'observer attentivement son déroulement vis-à-vis de son code source.
Trois variables entières sont initialement utilisées afin de représenter les différentes classes de stockage usuelles : Ces variables reçoivent une valeur initiale (quelques unités) et sont affichées ainsi que leurs adresses.
Un processus enfant est créé ; il modifie alors ces variables au niveau des dizaines alors que pendant ce temps son parent fait de même avec les centaines. Après avoir pris soin d'attendre un délai (excessif) pour que chaque processus ait le temps d'effectuer ses modifications, chacun d'eux affiche à nouveau ces mêmes variables et leurs adresses telles qu'il les voit.
Vous devez constater que, conformément à l'exercice précédent, l'enfant travaille bien sur une copie des données initiales (les unités initialement choisies sont conservées) mais qui est désormais distincte de l'original.
En effet, la modification des dizaines par l'enfant n'affecte pas les dizaines vues par le parent, et réciproquement pour les centaines.
Toutefois, en observant attentivement les adresses de ces variables affichées dans les deux processus, vous devez constater un paradoxe apparent : que la classe de stockage soit statique, automatique ou dynamique, une variable placée à une même adresse dans les deux processus semble avoir deux valeurs distinctes !

Bien entendu, il y a une explication : les espaces d'adressages manipulés par nos processus sont “virtuels”.
Le système d'exploitation qui gère nos processus donne des consignes à la MMU (Memory Management Unit) du processeur de la machine informatique pour associer les multiples plages d'adresses virtuelles de chaque processus (les pages) à des plages de mémoire physique.
Ainsi, lorsqu'un processus manipule ce qui est désigné par une adresse, cette adresse virtuelle est traduite par le processeur en adresse physique afin d'accéder à la mémoire physique.
Dans ces conditions, deux processus peuvent avoir des adresses virtuelles identiques (c'est le cas juste après fork()) mais qui correspondent à des pages physiques distinctes (le système en effectue une duplication après fork() si nécessaire✍).

Toutefois, il peut être justifié de souhaiter disposer d'une zone mémoire physiquement commune à plusieurs processus ; il faut alors faire la demande explicite d'un segment de mémoire partagée au système d'exploitation.
En complétant le point

{1}

du programme fourni, vous obtiendrez une quatrième variable qui, elle, sera placée dans un tel segment de mémoire partagée.
Comme à l'accoutumée, nous prenons soin de libérer cette ressource au niveau du point

{2}

lors de la terminaison de nos processus.

En reprenant l'examen attentif de ce que produit ce programme concernant cette nouvelle variable, vous devez constater quelle est bien partagée et que l'effet de chacun des deux processus est bien visible dans l'autre✍ :

Le cloisonnement par défaut des espaces d'adressage des processus est essentiel pour garantir l'intégrité du système d'exploitation : un processus ne peut se permettre de manipuler directement les données d'un autre.
Seules les applications qui sont explicitement conçues pour communiquer à travers un segment de mémoire partagée qui leur est commun en font la demande au système (elles doivent alors utiliser des moyens de synchronisation non décrits ici).

Documentation utile :

Nous travaillons sur le programme prog05_pipe.cpp.
Ce programme nous montrera que des processus apparentés peuvent communiquer à travers des “tubes”.

Les “tubes de communication” sont des ressources créées par le système d'exploitation et qui sont accessibles par des descripteurs de fichiers.
Seulement, contrairement aux fichiers, ils ne servent pas à stocker des données sur un support ; il ne s'agit que de fournir un espace de stockage temporaire dans la mémoire du système d'exploitation.
Un processus qui utilise un descripteur de fichier permettant d'écrire dans un tel tube ajoute des données dans cette zone mémoire.
Un processus qui utilise un descripteur de fichier permettant de lire depuis un tel tube extrait des données qui ont été préalablement ajoutées dans cette zone mémoire.
La communication à travers un tel tube est unidirectionnelle et garantit l'ordre des données ajoutées/extraites (First-In-First-Out).
Un tel tube est parfois qualifié d'“anonyme” par simple contraste avec la variante qui est usuellement qualifiée de “tube nommé”.

Pour revenir à notre réalisation, il s'agit ici de faire apparaître un processus enfant qui produira dynamiquement des données et les écrira dans un tube de communication.
Son parent obtiendra alors ces données en lisant depuis le même tube.
Puisque les descripteurs de fichier déjà ouverts dans un processus sont transmis lors de la création d'un processus enfant, il suffit d'ouvrir un tel tube de communication dans le processus initial avant qu'il crée son enfant.

En complétant le point

{1}

du programme fourni, vous créerez un tel tube de communication anonyme (il n'apparaît pas dans le système de fichiers).
Il est accessible grâce à deux descripteurs de fichier ouverts par l'appel système pipe().
Le premier permet de lire depuis le tube ; le second permet d'écrire dans le même tube.
Généralement, lorsque nous accédons à des ressources du système nous nous empressons d'envisager leur libération (ici la fermeture du tube).
Toutefois, exceptionnellement ici, puisque la fermeture de chacun des deux descripteurs de fichier à un rôle important dans le déroulement de la communication, nous traiterons leur fermeture au moment opportun.

Bien entendu, en l'état, un unique processus n'a aucun intérêt à relire ce qu'il écrit lui-même dans ce tube ; il nous faut donc créer un processus enfant qui en bénéficiera également.
En complétant le point

{2}

du programme fourni, vous ferez apparaître ce nouveau processus qu'il faudra au bout du compte attendre au niveau du point

{3}

à la terminaison.
Le point

{4}

doit repérer le processus enfant pour lui faire exécuter son traitement spécifique.
Celui-ci doit, quoi qu'il arrive, aboutir au point

{5}

pour provoquer la terminaison de ce processus enfant à la fin de l'alternative, ainsi, la suite du programme principal ne concerne que le processus initial (son parent).

Nous décidons arbitrairement dans cet exemple que c'est le processus enfant qui écrit dans le tube et son parent qui lit depuis le tube (nous aurions tout aussi bien pu décider l'inverse).
Puisqu'à ce stade de l'avancement de leur exécution nos deux processus ont accès aux deux descripteurs de fichier de cet unique tube, chacun d'eux doit fermer, au niveau des points

{6}

et

{7}

du programme fourni, le descripteur dont il n'aura pas l'utilité.
Après cela, chacun d'eux n'accède plus au tube que par le descripteur qui correspond à son intention (écriture ou lecture).

Dorénavant, la communication peut commencer.
Au niveau du point

{8}

, le processus enfant doit écrire une série de messages dans le tube et fermer le descripteur en écriture au niveau du point

{9}

pour signifier qu'il a fini de produire des données.
De manière complémentaire, son processus parent doit extraire au niveau du point

{10}

une série de messages jusqu'à obtenir la fin-de-fichier. Le tube ne pouvant alors plus fournir de données, le descripteur en lecture est fermé au point

{11}

puis qu'il est désormais inutile.

Pour tester ce programme, il suffit de le lancer sans argument $ ./prog05_pipe ↵ et vous devriez constater que le processus parent affiche petit à petit les messages produits par le processus enfant ; c'est bien ce qui est attendu.

Intervenez alors après le point

{8}

du programme fourni pour commenter l'appel à crs::sleep() ; les vingt messages produits par l'enfant vont désormais être écrits dans le tube à un rythme très soutenu.
Relancez le programme et observez attentivement la lecture des messages.
Vous devriez constater qu'il n'y a plus vingt réceptions distinctes mais que plusieurs messages, bien qu'ayant été produits séparément, peuvent être extraits en une seule opération : Nous constatons donc que si, entre deux opérations de lecture par le processus parent, le processus enfant a eu le temps d'écrire plusieurs messages, alors les messages ainsi accumulés dans la zone mémoire interne du tube ne forment qu'une unique séquence qui est potentiellement lisible en une seule opération✍.

Intervenez maintenant au niveau du point

{7}

afin d'oublier volontairement (en la commentant) la fermeture du descripteur en écriture dans le processus parent.
Relancez le programme et constatez que la boucle de lecture du processus parent ne se termine plus.
En effet, la fin-de-fichier n'est jamais détectée puisqu'il existe toujours un descripteur ouvert qui permet d'écrire dans le tube : celui que nous venons d'oublier de fermer dans le processus parent.
Le système d'exploitation ignore que notre programme n'a pas l'intention d'y écrire ; il estime donc que de nouvelles données peuvent apparaître dans le tube à tout moment et s'abstient de nous annoncer le fin-de-fichier.

À travers ces quelques essais vous avez réalisé la démarche usuelle de communication par tube anonyme et vérifié quelques propriétés :

Documentation utile :

Nous travaillons sur le programme prog06_redir_exec.cpp.
Ce programme nous montrera que les tubes anonymes facilitent la réutilisation de programmes déjà existants par redirection d'entrées/sorties et recouvrement dans un processus enfant.

En l'état, le programme fourni est assez proche de ce qui a été réalisé à l'étape précédente : une communication par tube est mise en place entre un processus enfant et son processus parent.
Seulement, quand on exécute ce programme $ ./prog06_redir_exec ↵ nous constatons que le processus parent ne détecte rien d'autre que la fin de fichier en provenance du processus enfant.
En effet, ce dernier, lorsque aucun paramètre n'est transmis sur la ligne de commande du programme, se contente d'afficher un message sur sa sortie standard avec crs::out() puis se termine avec crs::exit().
Le tube n'est donc pas du tout utilisé par le processus enfant, ce qui explique que le processus parent n'en obtient rien.

Intervenez alors au niveau du point

{1}

du programme fourni afin de procéder à la redirection de la sortie standard du processus enfant vers le tube (selon les recommandations des commentaires).
L'appel système dup2() sert à indiquer que la ressource désignée par son premier descripteur de fichier en paramètre (le côté écriture du tube ici) doit également être désignée par son second descripteur de fichier en paramètre (la sortie standard ici).
Juste avant cet appel, le descripteur de fichier de la sortie standard désignait le terminal ; juste après cet appel il désigne dorénavant le côté écriture du tube (tout comme le premier paramètre)✍.
Désormais, écrire dans le descripteur de fichier de la sortie standard provoquera le même effet qu'écrire dans le descripteur de fichier qui désigne le côté écriture du tube.
Ce dernier descripteur de fichier devient donc inutile puisque la sortie standard désigne dorénavant la ressource que nous avons l'intention d'utiliser (le côté écriture du tube) ; il est alors recommandé de fermer ce descripteur de fichier.

En relançant l'exécution de ce même programme, vous devriez constater que le message produit par le processus enfant dans sa sortie standard (crs::out()) n'apparaît plus directement dans le terminal mais est bien extrait depuis le tube par le processus parent qui peut l'exploiter à sa convenance✍.

En l'état, nous pourrions objecter que la redirection de la sortie standard vers le tube n'apporte pas grand chose par rapport à une écriture directe dans le tube comme nous le faisions à l'étape précédente.
En effet, en terme de rédaction de code source, il n'est pas plus compliqué d'écrire dans un tube que dans la sortie standard.
Cependant, cette démarche prend tout son intérêt si après cette redirection nous invoquons du code déjà existant qui écrit systématiquement dans la sortie standard (parce qu'il ignore simplement l'existence de ce tube).
Ce cas de figure est très fréquent lorsque nous effectuons un recouvrement de processus.

Pour mettre en œuvre cette démarche de recouvrement, nous allons utiliser comme prétexte la décompression d'un fichier au format "gzip".
Tout d'abord, en vue de l'expérimentation, obtenons un simple fichier qui contient du texte compressé grâce à la commande shell suivante : $ ls -l | gzip > output_file.gz ↵ (la liste détaillée du contenu du répertoire courant, affichée par la commande ls -l, est compressée par la commande gzip✍ et stockée dans output_file.gz).
Nous souhaitons donc que notre processus enfant consomme le contenu compressé du fichier output_file.gz, le décompresse et produise le contenu décompressé dans le tube de communication afin que le processus parent l'obtienne.
Seulement, pour réaliser cette opération nous allons nous appuyer sur l'utilisation telle quelle de la commande gunzip dans notre processus enfant.
En effet, cette commande, lorsqu'elle est utilisé sans argument, se contente de lire tout ce qui arrive sur son entrée standard, le décompresse, et inscrit le contenu décompressé sur sa sortie standard.

Il s'agit alors dans un premier temps d'effectuer les redirections d'entrée/sortie attendues.
Nous avions déjà redirigé la sortie standard au niveau du point

{1}

 ; il faut maintenant compléter le point

{2}

d'une manière très similaire afin que l'entrée standard du processus enfant ne corresponde plus à la saisie au clavier mais au fichier préalablement ouvert en lecture.

Il reste enfin à faire en sorte que le processus enfant exécute le code de la commande gunzip.
C'est ici qu'intervient la notion de recouvrement : il s'agit de complètement se débarrasser du code et des données d'un processus pour les remplacer par un tout nouveau programme qui démarre son exécution.
La fonction utilitaire crs::exec() (qui repose en interne sur l'appel système execve()) attend comme paramètre un tableau de chaînes qui sera interprété comme une ligne de commande : la première chaîne est le nom du programme, la seconde son premier argument...
Complétez alors le point

{3}

pour recouvrir le processus enfant par la simple commande gunzip.
Lorsque cet appel réussi (le programme exécutable existe) nous n'en revenons jamais !
En effet, tout le code qu'exécutait le processus enfant vient d'être remplacé par celui du programme choisi ; toute instruction qui suivait l'appel à crs::exec() n'est désormais plus accessible à ce processus.
Toutefois, ce recouvrement ne concerne que le processus enfant ; le processus parent n'a pas invoqué crs::exec() et continue d'exécuter son code pour exploiter ce qu'il extrait du tube de communication.
Il est important de noter que, bien que tout le code et toutes les données d'un processus sont remplacés lors d'un recouvrement, ses moyens de communication (tubes, fichiers...) restent ouverts et les redirections restent effectives.
Ainsi, le processus enfant qui exécute désormais la commande gunzip a bien son entrée standard reliée au fichier choisi et sa sortie standard au coté écriture du tube.

Dans ces conditions, vous pouvez tester votre programme en précisant le nom du fichier compressé sur sa ligne de commande. $ ./prog06_redir_exec output_file.gz ↵ Vous devriez constater que le processus parent obtient bien (et affiche) le contenu décompressé du fichier en question✍.
Grâce à la création d'un processus enfant, la redirection des ses entrée/sortie standards et le recouvrement par un autre programme, nous sommes parvenus à utiliser dans notre propre programme (le processus parent) les services d'un programme existant (la commande gunzip) en l'utilisant tel quel, sans avoir à le réécrire pour l'adapter à notre besoin.

Le recouvrement que nous venons d'expérimenter ici est un élément central des systèmes d'exploitation.
Il faut savoir que tous les programmes que nous lançons dans un système d'exploitation (automatiquement au démarrage, par la saisie d'une commande, en cliquant dans un outil...) reposent sur ce mécanisme.
Puisqu'il remplace le contenu d'un processus existant, il est très courant de faire apparaître un processus enfant juste à cette occasion, ce qui permet de conserver l'activité initiale du processus parent ; la séquence d'appels système fork()/execve() est très représentative du lancement d'un nouveau programme.
Les opérations de redirections d'entrées/sorties avec l'appel système dup2() prennent tout leur intérêt dans ce contexte car cela permet de relier entre eux et faire travailler de concert des programmes qui n'avaient pas été explicitement conçus dans ce but.
C'est d'ailleurs un point marquant de la manière dont ont été conçus les systèmes d'exploitation de la famille UNIX : proposer une multitude de commandes élémentaires et des moyens d'interconnexion pour les faire collaborer afin de réaliser des services de plus haut niveau✍.

Documentation utile :