IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 C Discussion :

File I/O et Standard I/O


Sujet :

C

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    56
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 56
    Points : 36
    Points
    36
    Par défaut File I/O et Standard I/O
    Bonjour,

    Je suis en train de lire Advanced Programing in the UNIX environment (une référence parait-il), et je bute sur des notions de base. Le chapitre 3 est consacré aux fichiers :
    We'll start our discussion of the UNIX System by describing the functions available for file I/Oopen a file, read a file, write a file, and so on. Most file I/O on a UNIX system can be performed using only five functions: open, read, write, lseek, and close. We then examine the effect of various buffer sizes on the read and write functions.
    The functions described in this chapter are often referred to as unbuffered I/O, in contrast to the standard I/O routines, which we describe in Chapter 5. The term unbuffered means that each read or write invokes a system call in the kernel. These unbuffered I/O functions are not part of ISO C, but are part of POSIX.1 and the Single UNIX Specification.
    Déjà la phrase en gras me pose problème : il est dit que les fonctions traitées ne font pas appel à des procédés de buffurisation (si j'ai bien compris). Pourtant, on parle dans se chapitre des fonctions du style sync() qui servent justement à vider les buffers dans lesquels l'OS stoke les données en attente d'écriture sur le disque ! C'est bien de la buffurisation non ??

    Bon à part ça je pensais avoir compris. Mais le chapitre 5 traite de la bibliothèque stdio.h, et je me demande quelle est la différence entre les fonction de cette bibliothèque, et celles vues au chaptitre 3 (write, read, open, creat, lseek + quelques autres moins importantes). En gros, c'est juste un moyen plus commode de gérer la lecture et l'écriture de fichiers c'est ça ?


    Edition : j'ai aussi un problème de compréhension de ce petit passage, où il est question des deux inconvénients du line buffering. Le second inconvénient, c'est que si j'ai un flux line-bufferisé et que je veux faire un input (écrire donc des données dans un fichier), tous les flux de sortie line-bufferisés de mon programme sont vidés ? Pourquoi ça ? Par ailleurs, est-ce que ça sous-entend qu'il y a deux deux buffers par flux, un pour l'input (écrire dans le fichier), et un pour l'output (lire les données d'un fichier) ?

    Line buffering comes with two caveats. First, the size of the buffer that the standard I/O library is using to collect each line is fixed, so I/O might take place if we fill this buffer before writing a newline. Second, whenever input is requested through the standard I/O library from either (a) an unbuffered stream or (b) a line-buffered stream (that requires data to be requested from the kernel), all line-buffered output streams are flushed. The reason for the qualifier on (b) is that the requested data may already be in the buffer, which doesn't require data to be read from the kernel. Obviously, any input from an unbuffered stream, item (a), requires data to be obtained from the kernel.
    Bon c'est vrai que ça fait beaucoup de questions, mais ce sont des choses qui ne sont pas évidentes à comprendre tout seul...

    Merci d'avance des éclaircissements que vous pourrez m'apporter,

    Silma

  2. #2
    Rédacteur
    Avatar de Neitsa
    Homme Profil pro
    Chercheur sécurité informatique
    Inscrit en
    Octobre 2003
    Messages
    1 041
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur sécurité informatique

    Informations forums :
    Inscription : Octobre 2003
    Messages : 1 041
    Points : 1 956
    Points
    1 956
    Par défaut
    Bonjour,

    Citation Envoyé par silma Voir le message
    Déjà la phrase en gras me pose problème : il est dit que les fonctions traitées ne font pas appel à des procédés de buffurisation (si j'ai bien compris).
    Les fonction POSIX provenant de l'en-tête <unistd.h> ne sont en effet pas "bufferisées".

    Pourtant, on parle dans se chapitre des fonctions du style sync() qui servent justement à vider les buffers dans lesquels l'OS stoke les données en attente d'écriture sur le disque ! C'est bien de la buffurisation non ??
    Il faut faire la différence entre la bufferisation en mode utilisateur et en mode noyau.

    fonctions déclarées dans <unistd.h>: pas de bufferisation en mode utilisateur.
    fonctions déclarées dans <stdio.h>: bufferisation en mode utilisateur (par défaut, mais contrôlable).

    Les fonctions d'<unistd.h> ne sont pas bufferisées en mode utilisateur (syscall direct) mais le sont au niveau du noyau. De manière schématique, au niveau de ce dernier (le kernel), il existe donc un buffer qui est "commit" vers le disque par le système - et ce de manière explicite - lors de l'appel à sync() (ou fsync() / fdatasync() ).

    Bon à part ça je pensais avoir compris. Mais le chapitre 5 traite de la bibliothèque stdio.h, et je me demande quelle est la différence entre les fonction de cette bibliothèque, et celles vues au chaptitre 3 (write, read, open, creat, lseek + quelques autres moins importantes). En gros, c'est juste un moyen plus commode de gérer la lecture et l'écriture de fichiers c'est ça ?
    cf. bufferisation en mode utilisateur.

    Edition : j'ai aussi un problème de compréhension de ce petit passage, où il est question des deux inconvénients du line buffering. Le second inconvénient, c'est que si j'ai un flux line-bufferisé et que je veux faire un input (écrire donc des données dans un fichier), tous les flux de sortie line-bufferisés de mon programme sont vidés ?
    Oui, le buffer de sortie est "flushé". Il utilise le terme "flush" qui signifie bien que le buffer est écrit vers le périphérique de sortie (file descriptor, stdout, stderr, ...).

    Note: stdout (donc pour un terminal) est automatiquement en line-buffering. Je ne pense pas que ce soit le cas avec pour les fichiers à tester avec __flbf() : http://linux.die.net/man/3/__flbf

    Pourquoi ça ?
    Intuitivement, je dirais que c'est surtout à cause du piping: on veut être sûr d'avoir la sortie avant de lire en entrée, sinon on risque un blocage ("hang / deadlock ", c-a-d que lire l'entrée alors qu'il n'y a rien du tout en sortie sera bloquant s'il n'y a absolument rien pour flusher la sortie).

    Par ailleurs, est-ce que ça sous-entend qu'il y a deux deux buffers par flux, un pour l'input (écrire dans le fichier), et un pour l'output (lire les données d'un fichier) ?
    Pour les streams du terminal (stdin, stdout, stderr) il y a bien un buffer pour chacun d'entre eux. Je ne pense pas que ce soit le cas pour les autres types de flux, ce qui serait bien trop consommateur en terme de mémoire.

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2010
    Messages
    56
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2010
    Messages : 56
    Points : 36
    Points
    36
    Par défaut
    Merci pour cette réponse fort détaillée ! J'avoue que beaucoup de choses sont encore très floues pour moi, et je trouve pas beaucoup d'exemples de code qui illustrent ces notions.

    Je reviendrai probablement très bientôt avec de nouvelles questions.

    Merci encore,

    Silma

  4. #4
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Neitsa Voir le message
    .
    fonctions déclarées dans <stdio.h>: bufferisation en mode utilisateur (par défaut, mais contrôlable).
    sauf l'écriture sur stderr, par défaut non-bufferisée (et je ne crois pas bufferisable)
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

Discussions similaires

  1. [File et Directory ListBox] Soucis de filtre
    Par Mercilius dans le forum Composants VCL
    Réponses: 8
    Dernier message: 04/04/2003, 17h17
  2. A propos des 'File management Functions' de Windows
    Par znaidi dans le forum Windows
    Réponses: 3
    Dernier message: 01/04/2003, 17h01
  3. Comment savoir qu'une fonction est standard ?
    Par D[r]eadLock dans le forum C
    Réponses: 5
    Dernier message: 24/03/2003, 15h42
  4. [librairies standard]slang.h et curses.h
    Par miss8 dans le forum Réseau
    Réponses: 13
    Dernier message: 27/12/2002, 11h14
  5. recupèrer file d'attente d'impression
    Par magic corp. dans le forum Langage
    Réponses: 2
    Dernier message: 25/09/2002, 15h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo