C'est dans le cas d'une application soft real time pour du son, avec
un processus écrit en C
d'un côté se connectant a "jack audio connection kit", et de l'autre
côté se connectant par une paire de
fifo (un pour l'acquisition audio, l'autre pour le playback) à un
processus écrit en Caml
(ou autre langage a garbage collector).
L'idée est de garder dans les fifos environ trois à cinq trames audio
(buffer de 64 à 1024 échantillons par canal), ce
qui fait office de tampon pour les cas ou le garbage collector côté
Caml (ou autre) vient à "voler" quelques centaines de micro secondes
ou quelques milisecondes au temps d'execution du traitement des
données côté Caml.
Une sorte de tampon élastique en terme de contrainte de temps entre du
C et du Caml, par l'intermédiaire des fifos.
Par contre, il serait très pratique d'avoir un appel système qui
retourne le nombre de bytes en transit dans le pipe afin
de synchroniser de manière précise/fiable les deux processus.
J'ai essayé fstat sans succès, côté écriture du fifo.
Le 9 nov. 09 à 16:03, Daniel Cordey a écrit :
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
_______________________________________________
gull mailing list
[email protected]
http://forum.linux-gull.ch/mailman/listinfo/gull
_______________________________________________
gull mailing list
[email protected]
http://forum.linux-gull.ch/mailman/listinfo/gull
