[gull] bytes en transit dans un FIFO

[Philippe Strauss]

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
> gull at forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull