Discussion :

[LePtitBen]

Bonjour

Je suis actuellement un cours sur la programmation Système, plus particulièrement sur le chapitre des processus.
On a abordé le principe de la fonction fork() qui va créer un nouveau processus. Mais je ne comprends pas réellement ce qu'il se passe avec le code. Par exemple, dans ce genre de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
void main(int argc, char** argv ){
  pid_t pid_fils;
  pid_fils = fork();
  if(pid_fils == 0){
    execlp("/bin/sh","sh", "-c",argv[1],NULL);
  }else{
    wait(NULL);
  }
}

De ce que j'ai compris, le fils va donc uniquement lire la partie du code où le pid_fils == 0. Mais je ne comprends pas réellement comme ça fonctionne.
Pourriez vous me donner une explication plus précise ?
Merci d'avance,

Ben

[Médinoc]

Pour expliquer ça, on peut partir de la signification du mot fork: Une fourche, comme sur la route. Une route qui se sépare en deux.
Voilà ce que fait fork(): Il sépare ton processus en deux processus identiques, à une différence près:
Il y a un lien de parenté entre les deux processus: L'un est le père et l'autre le fils, et l'OS n'aime pas que le processus père se termine avant le processus fils.

Ce qui est important à comprendre, c'est que lorsque fork() sépare le processus en deux, les deux processus résultats sont tous les deux au même point d'exécution: Ils sont tous les deux dans la fonction fork() qui n'a pas encore retournée. C'est un concept complètement différent de la création de processus telle qu'elle existe sous Windows, où un nouveau processus commence forcément du début.

La différence entre père et fils se manifeste de deux façons:

1. Chacun a son propre identificateur de processus (PID): Le père a le même PID qu'avant l'appel à fork(), alors que le processus fils a reçu un nouveau PID.
2. La valeur de retour de la fonction fork() diffère entre les deux: Dans le processus père, fork() va retourner le PID du processus fils; dans le processus fils, fork() va retourner zéro.

C'est comme ça que le processus fils exécutera uniquement le code dans le if(pid_fils==0), et le processus père exécutera uniquement le code du else.

[Sve@r]

Bonjour

De ce que j'ai compris, le fils va donc uniquement lire la partie du code où le pid_fils == 0. Mais je ne comprends pas réellement comme ça fonctionne.

Imagine le code suivant

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int main() {
	printf("Hello\n");
}

Si tu l'exécutes, tu auras une ligne affichée à l'écran. C'est parce que l'exécution de ce code est dévolue à un processus qui se charge d'exécuter ses instructions.

Maintenant, une toute petite modification

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int main() {
	fork();
	printf("Hello\n");
}

Au moment où le fork() s'exécute, il génère un second processus copie (et aussi appelé "fils") du premier. A partir de là donc, tout ce qui se situe en dessous sera traité (et exécuté) par deux processus tournant en parallèles. Et donc tu auras 2 affichage à l'écran car chaque processus affichera "Hello".

Jusque là c'est pas très intéressant d'avoir deux programmes faisant la même chose. Ce qui est intéressant, c'est de pouvoir distinguer qui est qui pour pouvoir leur faire faire des trucs distincts voire en collaboration.
Et le moyen de distinguer qui est qui se fait par le retour de la fonction fork(). Dans la branche fils elle retourne 0 et dans la branche père elle retourne le n° de pid du fils généré.

Tu peux, pour mieux distinguer les procesuss, modifier un peu le code

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int main() {
	fork();
	printf("Hello %d, %d\n", getppid(), getpid());
}

Là, on affiche le n° du processus père et celui du courant. Dans un des deux affichages tu auras (par exemple) 8700, 8701 et dans l'autre tu auras 8701, 8702 (parce que le ppid de l'un est aussi le pid de l'autre).

et l'OS n'aime pas que le processus père se termine avant le processus fils.

Pas d'accord. L'OS sait parfaitement gérer et dans ce cas, le processus devenu orphelin est alors rattaché à init, premier processus et père de tous les autres.

[Christophe]

Je rajouterais qu'une fois le processus fils créée, la fonction suivante est appelée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

execlp("/bin/sh","sh", "-c",argv[1],NULL);

Les fonctions de la famille exec chargent le programme en paramètre (/bin/sh dans ce cas) dans l'espace mémoire du processus appelant en écrasant donc le code courant. fork suivi de exec est la méthode utilisé pour lancer un programme sous Linux. Les fonctions exec ne retournent pas.

fork va utiliser le système du copy-on-write. Tant qu'il n'y a pas d'écriture, les 2 processus vont utiliser les mêmes zones mémoire, dès qu'il y a une écriture, la zone mémoire concernée est dupliquée et l'espace mémoire du processus concerné mis à jour en conséquence.

[LePtitBen]

D'accord, j'ai bien mieux compris ! Merci beaucoup !

[LePtitBen]

Après réflexions, j'ai quand même quelques questions.

Si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void main(){
  if(fork()==0){
    Blabla}
  if(fork()==0){
    Blabla}
  wait(NULL;)
}

Ici, je fais deux processus fils. Mais si le premier processus fils commence au premier fork. Il va donc lui aussi faire un fils avec le deuxième fork dans la boucle non ? J'aurais donc au total 3 processus fils non ?

[Sve@r]

Il va donc lui aussi faire un fils avec le deuxième fork dans la boucle non ?

Quelle boucle ? La boucle "if" ou la boucle "main" ???

J'aurais donc au total 3 processus fils non ?

Tu en auras tellement 3 qu'ils sembleront même être 4 si tu réfléchis bien.

PS: main() n'est pas void (voir mes exemples)

[LePtitBen]

Ba. Le premier fork() va exécuter tout ce qu'il y a en dessous du fork en terme de code si j'ai bien compris. Il va donc aussi créer un fils lui aussi avec le deuxième fork() dans le deuxième if, non ? ( Vu qu'il exécute tout ce qu'il y a après le fork). Donc au total, j'ai mon processus principal, mon premier fils qui en a fait un deuxième (donc le troisième) et un quatrième dans le dernier if qui va être créer par le père via le deuxième if. C'est ça ? Ou le fait de mettre le fork dans le if empêche à un premier processus fils d'accéder au deuxième if(fork()==0) ?

[Sve@r]

Le premier fork() va exécuter tout ce qu'il y a en dessous du fork en terme de code si j'ai bien compris.

Absolument. Ainsi je l'ai écrit, ainsi cela se passera.

Il va donc aussi créer un fils lui aussi avec le deuxième fork() dans le deuxième if, non ? ( Vu qu'il exécute tout ce qu'il y a après le fork).

Absolument (bis)

Donc au total, j'ai mon processus principal, mon premier fils qui en a fait un deuxième (donc le troisième) et un quatrième dans le dernier if qui va être créer par le père via le deuxième if. C'est ça ?

Exact. Donc ça fait bien 4 et non 3 comme tu avais dit tout à l'heure.

Ou le fait de mettre le fork dans le if empêche à un premier processus fils d'accéder au deuxième if(fork()==0) ?

Que nenni. Absolument tout le code situé sous le fork() est exécuté. Certains croient (à tort) que puisqu'ils ont isolé le fils ils sont tranquilles et que dans un code de ce genre...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
int main() {
	if (fork() == 0) {
		blabla;
	}
	printf("Hello\n");
}

Le "Hello" ne se fera que dans le père puisque (selon eux) le cas "fils" a été traité. Et ben non. Certes le cas "fils" fait l'objet d'un traitement "en plus" mais tout ce qui n'est pas isolé dans le cas "père" est alors traité par les deux.

Seule solution pour écrire un truc de ce genre: faire mourir le fils quand il a fini

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int main() {
	if (fork() == 0) {
		blabla;
		exit(0);
	}
	printf("Hello\n");
}

Là c'est bon. Sinon, il faut alors partir dans un code de ce genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
int main() {
	if (fork() == 0) {
		blabla;
	}
	else {
		printf("Hello\n");
	}
	// Et ne rien écrire entre cette accolade et la fin du main()
}

Et comme on est généralement attentifs aux posibilités/impossibilités de générer un fils, le code complet est généralement un code écrit sous cette forme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
int main() {
	switch (fork()) {
		case -1: // Erreur de fork()
			blabla... (gestion de l'erreur)
			break;
		case 0: // Fils
			blabla... (gestion du fils)
			break;
		default: // Père
			printf("Hello\n");
	}
	// Et ne rien écrire entre cette accolade et la fin du main()
}

Et sinon euh... t'as pas répondu à ma question pour m'aider à identifier la boucle dont tu parlais...

[LePtitBen]

Ok ! Merci de ta réponse ! Et je parlais de la deuxième boucle if, mais tu y as répondu.
Mais du coup, dans ce que j'ai écris, j'ai 2 fils qui vont faire la même chose non ? Ils vont tous les deux exécuter la deuxième boucle if non ?

[Sve@r]

Et je parlais de la deuxième boucle if,

Punaise... c'est vrai que vaut mieux lire ça que d'être aveugle... mais à peine. Sais-tu que tu es en très bonne position pour être le grand gagnant de ce forum ? Réfléchis-tu parfois au sens des mots que tu emploies ???

Mais du coup, dans ce que j'ai écris, j'ai 2 fils qui vont faire la même chose non ? Ils vont tous les deux exécuter la deuxième boucle if non ?

"if" n'est pas une boucle !!!

Mais sinon effectivement chaque fork() exécute deux fois de façon identique tout ce qui est en dessous.

[LePtitBen]

Je prends note de ta remarque !
On m'a encouragé à mettre un wait(NULL) dans mon main lorsque je fais à chaque fois un fork(). Est-ce que cela peut influencer le comportement de ses fils ? Car la seule chose que j'ai pu comprendre en lisant la doc, c'est que le père attend simplement que le fils fini avant de continuer, c'est bien cela ?

[Christophe]

wait suspend un processus en appelant un autre jusqu'à que l'un de ses fils se termine. Ça influence donc le père mais pas les fils.

[Sve@r]

Car la seule chose que j'ai pu comprendre en lisant la doc, c'est que le père atteint simplement que le fils fini avant de continuer, c'est bien cela ?

Exact. Donc pas d'influence sur les fils. Ca permet juste de synchroniser le truc pour être plus propre (le père lance un fils puis il attend la fin de son fils avant de se terminer).