[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