IFT-2001 / Automne 2026 / Processus et appels système

Mini-test — Processus et appels système

Exercices d’entraînement créés pour le portail. Aucun questionnaire officiel. Banque v1.

8 questions. Un point par réponse automatique correcte; aucun crédit partiel. Les autoévaluations sont comptées séparément. Les corrigés apparaissent après chaque réponse; ce mini-test sert à apprendre.

Toute la banque

Aucune tentative commencée.

1. Père PID 34, fils créé PID 35 : quelles valeurs pour (retour de fork, getpid) dans chaque branche ?

Application · version 1

Hypothèses et règle de réponse

Un fork réussi; PID illustratifs; le fils et le père continuent après l’appel.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 1

La variable de retour ne représente pas nécessairement l’identité de l’appelant. Le père reçoit le PID du fils, le fils zéro; getpid donne l’identité propre. La valeur de branche est fixée, l’ordre d’exécution ne l’est pas.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 5.1 `fork()`Revoir la matière — 5.2 Trace représentative

2. P0 exécute deux appels fork successifs F1 puis F2 sans branche ni sortie entre eux. Chaque processus atteint chaque appel restant. Construisez l’arbre, comptez les processus et distinguez les créations des ordres d’affichage.

Application · version 1

Hypothèses et règle de réponse

Tous les fork réussissent; processus initial unique; aucun exec, signal ni fin avant le deuxième appel.
Nommer P1 le fils créé par P0 en F1, P2 celui créé par P0 en F2, P3 celui créé par P1 en F2. Les noms désignent la parenté, pas l’ordre des PID.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 2

Le dédoublement est 1→2→4 sous ces hypothèses. Une trace possible effectue F1, F2 de P1 puis F2 de P0; l’inverse des deux F2 est possible. P1 peut donc créer P3 avant que P0 crée P2. Une branche, un échec ou un exec avant F2 change le comptage; les PID numériques ne sont pas imposés.

Après F1 : P0 et P1; chacun atteint F2.
P0 crée P2 en F2; P1 crée P3 en F2 : quatre processus finaux et trois créations.
Arêtes : P0→P1, P0→P2, P1→P3. P2 et P3 commencent après leur propre F2 et ne refont pas F1.
F1 de P0 précède les deux F2; les deux F2 ne sont pas ordonnés entre eux. L’arbre ne détermine aucun ordre global d’affichage.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 5.2 Trace représentative Revoir la matière — 4. Création et parenté des processus

3. Le fils PID 35 réussit exec puis l’ancien code contient afficher("ancien"). Quelle garantie ?

Application · version 1

Hypothèses et règle de réponse

exec réussit; on distingue l’ancien programme du nouveau.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 3

exec charge une nouvelle image dans le processus courant et ne crée pas de PID. Le succès ne revient pas à l’ancien flot; un retour signale une erreur à traiter. Les variantes l/v reçoivent liste/tableau; p recherche dans PATH. Le nouveau programme peut ensuite créer d’autres processus, ce qui est distinct.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 5.3 `exec*()`

4. Après fork, le père émet A puis waitpid(fils, sans WNOHANG), puis B. Le fils émet F, réussit exec; le nouveau programme émet E et termine. Donnez tous les ordres de A,F,E,B et expliquez l’absence de retour à l’ancien code.

Application · version 1

Hypothèses et règle de réponse

Un seul fils; fork, exec et waitpid réussissent; waitpid revient pour la terminaison visée, pas un arrêt.
Événements indivisibles observables, sans tampon ni duplication de tampon; aucun autre événement ni signal.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 4

Contraintes A<B, F<E et E<B. Placer A avant F, entre F et E ou après E donne AFEB, FAEB, FEAB. Aucun ordre n’est garanti entre A et F, ni entre A et E. En cas d’exec échoué, d’attente interrompue ou non bloquante, les hypothèses changent. Le PID du fils reste identique à travers exec.

F précède E : exec réussit et le nouveau programme émet E; l’ancien code après exec ne s’exécute pas.
A précède B dans le père; E précède la fin du fils puis le retour de waitpid et B.
Les trois ordres complets sont AFEB, FAEB et FEAB; B est toujours dernier.
waitpid peut revenir immédiatement si le fils est déjà terminé; il récolte son statut sans fusionner les mémoires. sleep ne remplace pas cette dépendance.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 5.4 `wait()` et `waitpid()`Revoir la matière — 5.3 `exec*()`Revoir la matière — 5.2 Trace représentative

5. x vaut 5 avant fork; le fils fait x+=15 puis termine. Le père attend sa fin et lit x. Quelle valeur et pourquoi ?

Application · version 1

Hypothèses et règle de réponse

fork et attente réussissent; variable ordinaire privée; aucun mécanisme de partage explicite.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 5

Les pages peuvent d’abord être partagées physiquement et protégées. Une écriture demande une copie privée de la page concernée dans le modèle copy-on-write. Cela ne transforme pas les espaces en mémoire partagée; l’attente synchronise la fin sans transférer x.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 6. Mémoire après `fork` et copie sur écriture

6. Quelle chaîne représente une demande read depuis une bibliothèque ?

Compréhension · version 1

Hypothèses et règle de réponse

Modèle pédagogique du maître S03; aucune commande exécutée ni manipulation réelle attestée.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 6

Bibliothèque, instruction d’entrée, répartiteur et routine de service sont des niveaux distincts. Le noyau vérifie pointeurs, tailles, descripteurs et autorisations. Une bibliothèque peut rester en espace utilisateur; la transition protégée ne rend pas la demande automatiquement valide.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 10.2 Mécanique générale Revoir la matière — 10.1 API, bibliothèque et noyau Revoir la matière — 8.4 Privilèges

7. On veut filtrer stdout de a vers b et capturer stdout+stderr de cmd dans journal.log en le remplaçant. Quel couple est correct ?

Application · version 1

Hypothèses et règle de réponse

Bash; redirections ouvertes avec succès; fichiers de l’exercice fictifs, aucune commande exécutée.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 7

Le tube transporte stdout; && dépend du succès et || de l’échec; ; exécute ensuite indépendamment. > remplace, >> ajoute, < choisit l’entrée. Les redirections se traitent de gauche à droite : > journal.log puis 2>&1 donne aux deux flux la destination fichier. L’ordre inverse laisse stderr sur l’ancienne stdout.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 14.3 Opérateurs Revoir la matière — 14.2 Exercices 9 à 14

8. Après lancement du serveur en arrière-plan, quel usage de $!, kill et trap EXIT est exact ?

Application · version 1

Hypothèses et règle de réponse

Bash; lancement direct illustratif; le PID sauvegardé désigne encore le serveur de cet exercice; aucune commande réelle ni garantie de disponibilité serveur.

Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Corrigé — question 8

Le maître dit que trap garantit le nettoyage : préciser la portée. Une sortie normale ou exit anticipé exécute l’action EXIT; SIGKILL ou une panne ne permet pas son exécution. kill demande un effet selon le signal; attendre et contrôler l’état peut être nécessaire. Un simple sleep ne prouve pas la disponibilité; curl et son code de retour fournissent le test prévu sur 8000. Ces explications ne certifient ni serveur lancé ni exercice réussi.

Variantes : Les hypothèses fixent le problème. Noms/PID fictifs peuvent changer sans modifier le raisonnement; les réponses rédigées suivent la rubrique et restent autoévaluées.

Revoir la matière — 15.2 Exercice 15 — test d'un serveur Revoir la matière — 15.5 Ce que vérifient les scripts de correction Revoir la matière — 7. Terminaison, zombies et orphelins

Récupérer manuellement les données locales

Copier séparément les données ci-dessous dans des fichiers texte avant de fermer la page ou de modifier le stockage. Une valeur illisible ou incompatible reste en place. Aucun effacement ni rétablissement écrasant n’est effectué automatiquement. L’export/import JSON est disponible sur la page Progression du cours. Cette récupération séparée reste utile pour une valeur brute ou un conflit.

Clé de ce cours : . Format v1 porté par cette clé; dates UTC et identifiants durables.

État valide en mémoire (JSON) Valeur brute lue dans le stockage (copier même si illisible) Données en conflit à conserver séparément (JSON)

Si l’accès est refusé, la valeur persistée peut rester inaccessible. Réautoriser le stockage dans le navigateur puis rouvrir ce cours permet de la relire. Une réinitialisation exige une décision explicite après récupération; aucune commande de suppression n’est proposée ici. Les données restent sur cette origine et cet appareil, sans transfert automatique.