un probleme avec fork()

Bonjour :).
S'il vous plait je vous invite à tester ce bout de code car j'ai trouvé une chose bizarre.

En fait ça m'affiche un nombre d'étoiles très grands

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include<stdio.h> #include<sys/file.h> #include<unistd.h>   int main() { int i=0; for(i=0;i<5;i++) { fork(); printf("*");   } }

---

ce pendant en ajoutant "\n" ça donne un résultat correct :roll:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include<stdio.h> #include<sys/file.h> #include<unistd.h>   int main() { int i=0; for(i=0;i<5;i++) { fork(); printf("*\n");   } }

---

Normalement dans les 2 cas t'as le même nombre d'étoiles (de l'ordre de !5 intuitivement), sauf que dans le second cas t'en as une par ligne.

Quant à savoir quel est le résultat correct, ça dépend de la spécification du programme ;-)

le résultat correct est 31 sans aucun soucis mais en ajoutant \n ça change toute la philosophie :calim2:

Je ne comprends pas ton problème ni ta "philosophie". Un "\n" c'est un retour à la ligne. La seule différence entre tes 2 programmes c'est que dans l'un les étoiles sont sur une même ligne alors que l'autre il y a une étoile par ligne...

Citation:

---

Envoyé par maestroENSI

le résultat correct est 31 sans aucun soucis mais en ajoutant \n ça change toute la philosophie :calim2:

---

Je viens de faire le test chez moi aussi et je me suis donné des sueurs froides pendant une heure au moins car j'obtenais des résultats structurés…

En fait, c'est dû à un problème très subtil : quand tu fais printf(), ce que tu écris va dans un buffer pour être envoyé vers la sortie en une fois. Or, quand tu fais fork(), le processus fils hérite de toute la mémoire du père, y compris ce qu'il maintient dans le buffer ! Le contenu de celui-ci est donc dupliqué.

J'ai eu peur parce qu'en principe, un retour à la ligne vide ce buffer et c'est ce qui se passe chez toi. Mais sur mon Linux, apparemment, le retour à la ligne provoque bien le vidage mais pas forcément pendant le printf(), visiblement, et le fork() avait donc le temps d'hériter du buffer. Ça faisait drôle parce que, même en écrivant à l'écran le contenu de i, j'obtenais 16 tours de boucle pour i=0, 8 tours pour i=1, 4 pour i=2, etc.

D'autre part, tu forkes avant d'afficher l'étoile et non après. Tu obtiendras donc 62 étoiles et non 31.

Oui c'est un problème classique avec fork() :mouarf:

D'une manière générale c'est toujours une bonne idée de faire un fflush(NULL) avant un fork() si on ne va pas faire un exec() juste derrière.

Citation:

---

Envoyé par matafan

Oui c'est un problème classique avec fork() :mouarf

---

Le buffer dupliqué, oui. Mais le fait d'obtenir des résultats mathématiquement cohérents dans ce cas précis m'a collé un doute…

En remplaçant le printf("*") lourd et bufferisé par fputc('*', stdout) léger et direct, on s'enlève une grosse épine...

fputc() est bufferisé, comme tout ce qui utilise les FILE *.

Pour faire une sortie non bufferisée il faudrait soit changer la politique de bufferisation avec setvbuf(), soit faire un sortie directe avec un write() sur STDOUT_FILENO.

Citation:

---

Envoyé par matafan

fputc() est bufferisé, comme tout ce qui utilise les FILE *.

---

Ouais. J'ai dit une connerie. En plus j'ai écrit fputc() en pensant à write(). Bon bref un post pour rien quoi...:aie:

Citation:

---

Envoyé par Sve@r

Ouais. J'ai dit une connerie. En plus j'ai écrit fputc() en pensant à write(). Bon bref un post pour rien quoi...:aie:

---

ça arrive.....

effectivement ce problème système est amusant.

Citation:

---

Envoyé par jabbounet

effectivement ce problème système est amusant.

---

Ben surtout on apprend des choses. Parce qu'on a beau être à l'aise avec les fork(), je n'ai jamais été confronté au pb de buffer non vidé avant le fork et dupliqué dans le fils. Et si j'y avais été confronté d'un coup, j'aurais été vraiment sec. Je retiens la solution fflush(NULL) avant tout fork...