Séquence écritures dans fichiers

Bonjour à tous,

J'ai un processus qui écrit une chaîne de caractères dans un fichier au moyen de fprintf n fois.
A chaque itération, n fait partie de la chaîne de caractères écrite.

Lorsque j'ouvre le fichier produit, j'observe bien que n est croissant au fur et à mesure des lignes écrites.

Si le nombre d'écritures est très très grand, est-il possible que les écritures se mélangent et que n ne soit plus strictement croissant?

Merci

Il ne peut y avoir mélange que si :
- tu es multithreadé.
- tu mélanges des 'fprintf(stdout' avec des 'fprintf(stderr' et que que tu rediriges les deux dans ton log.

Citation:

---

Envoyé par valefor

Il ne peut y avoir mélange que si :
- tu es multithreadé.
- tu mélanges des 'fprintf(stdout' avec des 'fprintf(stderr' et que que tu rediriges les deux dans ton log.

---

Ou encore, que deux processus distincts (donc pas des threads) écrivent dans le même fichier. C'est possible aussi, spécialement si on lance deux fois le même programme par erreur.

Citation:

---

Envoyé par barnoufal

Si le nombre d'écritures est très très grand, est-il possible que les écritures se mélangent et que n ne soit plus strictement croissant? Merci

---

Non, il n'y aucune raison pour que ton ordinateur « s'emmêle les pinceaux » et ne suive plus le fil. Par contre, la variable que tu vas utiliser pour faire le compte a une importance. Avec un unsigned long int 32 bits, tu peux compter jusqu'à 4.294.967.295 (0xffffffff). Donc, passé tes quatre milliards de ligne (il faut les faire, déjà), ton compteur risque de revenir à zéro. Avec un unsigned long long int sur 64 bits, en revanche, cela sera aussi le cas, mais il faudra trois ou quatre millénaires à une machine moderne pour en faire le tour, et quelques milliards de disques durs pour stocker le résultat.

Citation:

---

Envoyé par Obsidian

Ou encore, que deux processus distincts (donc pas des threads) écrivent dans le même fichier. C'est possible aussi, spécialement si on lance deux fois le même programme par erreur.

---

Je ne pense pas. Je ne sais plus dans quel man j'avais vu l'explication, je vais rechercher.

En attendant, un petit exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <stdio.h>   #include <signal.h>   static int stop = 0;   void handler(int signum) { fprintf(stderr, "sigint\n"); stop = 1; }   int main(int argc, char **argv) { signal(SIGINT, handler);   while(!stop) { fprintf(stdout, "%s\n", argv[1]); } return 0; }

---

Lances deux fois ce programme avec un paramètre différent.

Citation:

---

Envoyé par valefor

Lances deux fois ce programme avec un paramètre différent.

---

Résultat sur mon terminal :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

$ ./ecrire Un Un Un Un … <Ctrl-Z> $ ./ecrire Deux Deux Deux Deux … <Ctrl-Z> $ bg Deux Deux Deux … ($ bg) Un Deux Un Deux Un Deux Un Deux …

---

Il n'y a aucune raison que cela ne se produise pas. Un fichier peut tout-à-fait être ouvert plusieurs fois en lecture et en écriture (ou alors, le système est anté-diluvien). Il faut poser un verrou explicite pour l'ouvrir en accès exclusif, et faire attention à ce que l'on fait. Sous Linux, les verrous flock() sont consultatifs. Il faut monter le système de fichiers avec une option spéciale (-mand : mandatory) pour les rendre impératifs.

Le seul problème qu'un processus peut connaître est lorsqu'il lit l'entrée standard et qu'il est en tâche de fond. Comme l'entrée standard ne peut être dirigée que vers un seul processus, il reçoit un SIGSTOP.

Héhé, au temps pour moi. Deux gourdes : ma manip qui n'était pas bonne et ma mémoire qui me fait défaut.

Vivement le we, merci pour ta correction.

Merci pour vos réponses!