voila je me pose la question  
 
poiuvez m'expopliquez en 2-3 mots
fread :
je sais que une fois le buffer vide ( ou plein pour un fwrite) y a un appel et apres sémaphore je pense  
et puis le proc regarde si c important ou pas pour traiter une E/S. si pas important c'est mis en attente en mode "attente" ou je ne sais plus trop quoi bloquant ...
 
alors que le read appelle directement un appel systeme
 
EDIT : post corrigé

Je suis desole mais je n'ai strictement rien compris a ta question (et je ne crois pas que cela vienne de moi).
 
de plus je ne connais que fread en ANSI C. Quelqu'un pourrait confirmer? De meme il me semble que read c'est du C++.

 
Tu devrais lire mon topic posté y a 2/3 jours.
 
read() est un appel système, c'est un system call unix.
_read(), c'est l'équivalent windows me semble-t-il.
quant à fread(), ca fait partie de la librairie C standard et c'est bufferisé. fread utilisent les fonctions fournies par le système (donc read/_read/etc.) A utiliser quand on veut donc quelques choses de portable et bufferisé
 
Ensuite de temps à autre, fread ne suffit pas parce que le buffer n'est pas optimisé pour l'utilisation qu'on en a et surtout, il n'informe pas quand une donnée est vraiment inscrite sur le disque, etc. (encore une fois, voire mon sujet précédent).

tes critiques sur read sont infondées, read a les memes défauts. tu n'as aucune assurance de synchronisation, le noyau ayant ses propres buffers. la solution c'est d'utiliser fsync si dispo, ou  fflush qui fonctionne tres bien.
 
je crois que vous petéz un plomb. y a pas plus lent que read, y a pas plus lent qu'un appel système

Angel_Dooglas -> oui je te comprends j'ai loupé la moitié des mots, c'est normal que tu puisse pas comprendre ....
je pense que j'ai posté ds la bonne section, j'ai posté dans la section C et non pas C++. cela me semblerait logique qu'il n'y ait pas read en C++ car ce language ne permet pas de travailler aussi bas que C. avec le read comme je l'ai dit c'est toi qui déclenche direct un appel système et pour faire ca je pense que c++ soit fait pour ca.  
 
Willyzekid -> je connaissais pas _read pour windows, merci  
 
++Taz -> tu voulais parlais de fflush pour fread je pense qui te permet de vider le flot ou flux .....
 
 
 

 
le fflush, c'est plutôt pour les fichiers ouvert en écriture, non ? Parce qu'en lecture, je vois pas trop l'intérêt ... Par contre, en écriture, ca force à écrire le contenu du buffer sur le disque (physiquement quoi)

 
Je suppose que tu veux dire pas plus rapide.

de toutes facon en tant qu utilisateur on n'a pas le choix, ce sont les seuls acces aux peripheriques et/ou fichier.
 
 
Le principal interet de read par rapport a fread , c que fread ne sert que pour les fichiers (arretez moi des maintenant si je me trompe)
 
Par contre read permet de lire sur un descripteur, soit un fichier mais aussi un peripherique (/dev/ttyS0 pour lire sur le port serie) , sur un tube, une socket etc... voila.
 
Pour flusher un write par contre je ne sais pas comment faire... mais il me semble que si ca n est pas un fichier, le flush est automatique a la fin de l appel de la fonction ( j'en ai fait les frais d ailleurs :-p )

fo, on peut construire des FILE* à partir de n'importe quell descripteur. et pour write, y a pas de flush automatique, vous mélangez tout. write tout comme write reviens quand l'opération est terminé. le noyau à lui aussi des tampons, donc quand write reviens , rien ne te garantit que le noyau vide les ses tampons et finalise les ecritures. encore une fois voir fsync!!!!!!!!!  

ok , merci pour la precision.
 
edit : je ne savais pas pour le fwrite , qu on pouvait ouvrir des flux sur des sockets, tube ou autre.

man fdopen

 
oui mais le noyau, quelqu'il soit, a ses propres routines de syncronisation (_commit pour Win, etc.) avec lesquels tu es sûr que les données sont inscrites quand tu le veux sur le disque.
 
Il n'y a aucun moyen de vérifier ca avec FILE*, fflush ne te garantie pas l'écriture sur le disque mais il te garantie l'écriture dans le buffer de l'os...

et fsync bordel!!!!!!!!!!!!!!!!!!!

 
Aya...
 
fsync, c'est un call unix, equivalent à _commit de windows. Ca n'appartient absolument pas à la librairie standard...
 
Pour vérifier qu'un buffer est bien inscrit sur le disque les fonction de la librairie standard architecturées autour de FILE* ne suffisent pas... Tu es obligé, comme tu viens toi même de le démontrer, d'utiliser les routines du système comme fsync ou _commit.
 

ça j'avais bien compris, cela dit la lecture du topic montre clairement que l'on s'interesse aux appels systèmes. si tu veux chercher la mouche, n'importe quel sync n'assure juste que le transfert vers les buffer du système E/S, donc on a aucune assurance de l'écriture physique sur le disque

 
Ben ouais c'est ce que je disais dans mon premier poste...On s'est pas compris dés le départ apparement.
 
D'un autre coté, j'étais en train de me demander si fflush() n'écrivait effectivement pas sur le disque...Mon programme de test n'écrit rien sur le disque mais les descriptions de fflush que je trouve se contredisent allégrement.

  t'auras jamais aucune garantie puisque c'est le disque qui gère ses buffer plus ou moins comme bon lui semble (surtout en SCSI)

 
D'autant plus qu'un système de fichier comme NTF va journaliser les écriture disque et les différer.

NTF?

S
 
  Oublié une lettre, désolé

je crois que t'as pas conscience que la journalisation de NTFS a un train de retard...

Développe stp.

 
Précise ta pensée stp.
 
Grillé  

Non, on est pas là pour ça.

 
Merde pour une fois qu'on discute de trucs intéressants, on se fait un chtit topique alors?

pas sur cette cat alors, viendez en territoire ennemi sur OSA si vous osez

 
Attend je prend mon équipement d'aventurier et j'arrive  

La suite ici alors ...
http://forum.hardware.fr/forum2.ph [...] subcat=205
 
(Franchement je vois pas en quoi justifier tes propos en 2 lignes histoire de donner des pistes de recherche est HS).

parce que