Qui connaît l’histoire de la fourche Unix?

Fork est un excellent outil dans unix.Nous pouvons l’utiliser pour générer notre copie et changer son comportement.Mais je ne connais pas l’historique de fork.

Est-ce que quelqu’un peut me raconter l’histoire?

En réalité, contrairement à la plupart des fonctionnalités UNIX de base, fork était un retardateur relatif (a) .

La première existence de processus multiples dans UNIX consistait en quelques processus (nombre fixe), un par terminal associé à la machine PDP-7 (b) .

L’idée de base était que le processus shell pour un terminal donné accepterait une commande de l’utilisateur, localiserait le fichier programme, chargerait un petit programme bootstrap en mémoire vive et passerait assez de détails pour que le code bootstrap charge le fichier programme. .

Le code bootstrap, après avoir chargé le programme en mémoire basse (écrasant le shell), sautait alors au code.

Une fois le programme terminé, il appellerait exit mais ce n’est pas la exit nous connaissons et aimons aujourd’hui. Cette exit rechargerait simplement le shell et l’exécuterait en utilisant à peu près la même méthode que celle utilisée pour charger le programme.

Donc, c’était plutôt une commande exec rudimentaire, celle qui remplace votre programme actuel par un autre, dans le même espace de processus.

Le shell exec votre programme puis, une fois le programme terminé, il exec nouveau le shell en appelant exit .

Cette méthode était similaire à celle de nombreux autres systèmes interactifs de l’époque, y compris les Multics d’où UNIX tire son nom.

À partir de l’ exec bidirectionnel, l’ajout de fork tant que duplicateur de processus n’a pas été un grand pas en avant. Alors que de nombreux systèmes exécutent directement un autre programme, c’est la méthode “juste append ce qui est nécessaire” qui est responsable de la séparation des tâches entre fork et exec dans UNIX. Cela a également entraîné une fonction de fork très simple.

Si vous vous intéressez à l’histoire des différentes fonctionnalités (c) d’Unix, vous ne pouvez pas dépasser l’article The Evolution of the Unix Time-Sharing System par Dennis Ritchie, présenté lors d’une conférence en Australie en 1979, puis publié par AT & T .


(a) Bien que je parle de retardataire en ce sens que la séparation des quatre forces fondamentales dans l’univers était “tardive”, se produisant environ 0,00000000001 secondes après le big-bang. .


(b) Comme une question a été soulevée dans un commentaire sur la façon dont les obus ont été lancés, il existe une excellente ressource contenant un code source très ancien pour Unix chez The Unix Heritage Society , en particulier les archives du code source et première édition .

Le fichier init.s de la première édition montre comment le nombre fixe de processus shell a été créé (légèrement reformaté):

  ... mov $itab, r1 / address of table to r1 1: mov (r1)+, r0 / 'x, x=0, 1... to r0 beq 1f / branch if table end movb r0, ttyx+8 / put symbol in ttyx jsr pc, dfork / go to make new init for this ttyx mov r0, (r1)+ / save child id in word offer '0, '1, etc br 1b / set up next child 1: ... itab: '0; .. '1; .. '2; .. '3; .. '4; .. '5; .. '6; .. '7; .. 0 

Vous pouvez voir ici l’extrait de code qui crée les processus pour chaque terminal connecté. Ce sont les jours de valeurs codées en dur, pas de détection automatique de la quantité de terminal impliquée. La table terminée par zéro sur itab est utilisée pour créer un certain nombre de processus et j’espère que les commentaires du code expliquent comment (le seul bit potentiellement délicat est les étiquettes – bien qu’il y ait plusieurs étiquettes 1 , vous vous twigz sur la plus proche direction, donc 1b signifie l’étiquette 1 la plus proche en arrière).

Le code affiché traite simplement la table, appelant dfork pour créer un processus pour chaque terminal et démarrer getty , l’invite de connexion. Le programme getty , à son tour, a finalement démarré le shell. A partir de là, c’est comme je l’ai décrit dans la partie principale de cette réponse.


(c) Aucun chemin (et utilisation de liens temporaires pour contourner cette limitation), processus limités, pourquoi il y a un champ GECOS dans le fichier de mot de passe et toutes sortes d’autres anecdotes, généralement intéressantes uniquement pour les utilisateurs expérimentés.