[gull] bytes en transit dans un FIFO
Daniel Cordey
dc at mjt.ch
Mon Nov 9 16:03:35 CET 2009
On Monday 09 November 2009 15:38:10 Philippe Strauss wrote:
> en C, comment peut-ont connaître le nombre de bytes en transit/contenu
> dans un fifo (mknod/mkfifo) (si cela
> est seulement possible), genre un appel stat ou ioctl, mais lequel?
A un instant t ? Compter les bytes qui transitent par un pipe est facilement
realisable en "interceptant" tout ce qui passe par le canal... c'est juste uen
fonction relai (macro) en C.
Par contre, il est difficile de realiser des fonctions d'interceptions pour
avoir un "etat des lieus" a un instant t sans introduire un overhead ou un
delai qui peut etre non-desire. Le probleme est que l'on doot dans ce cas
inroduire un traitement asynchrone de l'utilisation du "pipe/socket". Ceci se
fait en utilisant "select(2)", mais il y a un certain nombre de chose dont il
faut tenir compte dans l'interpretation du resultat...
Lors du write(), le retour de la fonction va engendrer un context-switch, ce
qui va certainement engendrer un re-examen du "process le plus elligible" pour
le CPU. Donc, avant que l'on ait eu la chance de faire un autre systeme call
(fstat, ioctl, etc.) il se peut que le controle soit passer justement au
procesus en lecture sur le pipe... (process lui aussi soumis au context-
switch) Il est quasimment impossible d'obtenir une valeur ou un decompte
absolu. Tout au plus peut-on obtenir des valeurs "statistiques" mais dont on
aura de toute facon de la peine a preciser les valeurs extremes. Au mieux, on
peut garantir qu'a un instant t, le buffer du pipe contient entre 0 et 8K bytes
:-) Franchement, plus j'y pense, plus il m'apparait difficile de mesurer ce
genre d'evenement avec precision... A mon avis, il n'y a pas de methode
deterministe pour ce genre d'operation.
Maintenant, j'ai peut-etre compris la question de travers ou je complqiue
trop... mais... plus tes processus de mesure seront lents, moins tu auras de
bytes dans le buffer du fifo... :-)
Et si tu nous expliquais le probleme avec une vue un peu plus generale ?
dc
More information about the gull
mailing list