[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE : RE : RE : [Tsp-devel] Ordr e d'arrivée des samples d'un groupe
From: |
Eric Noulard |
Subject: |
Re: RE : RE : RE : [Tsp-devel] Ordr e d'arrivée des samples d'un groupe |
Date: |
Thu, 21 Dec 2006 10:24:39 +0100 |
Le 21/12/06, TSP<address@hidden> a écrit :
Salut,
Si on rajoute dans la spec des fournisseurs :
que le provider doit répondre dans l'ordre de la demande,
Que le provider doit mettre la date dans le PGI zero,
cela peut il arranger les choses ?
Mon avis: NON SURTOUT PAS !!
Y a-t-il une impossibilité de développement ?
Ce n'est réellement à moi de répondre mais voici
mon avis ci-après.
Quelque bonnes (à mes yeux) raisons de ne pas ajouter de contraintes d'ordre:
0) Celui qui code un nouveau provider ne code
qu'un "GLU" et c'est la lib TSP qui décide du reste
(avec l'aide du GLU mais pas seulement)
de l'ordre d'envoi des samples (au sein d'un même cycle) etc...
Donc ce n'est pas à celui qui "code" un provider d'assurer
ce genre de chose, puisqu'il risque tout simplement
de ne pas pouvoir le faire.
En revanche l'obliger à inclure un symbole "date" ou "time"
ou etc... dont le PGI est 0 est une contrainte "raisonnable".
1) Du point de vue de TSP une "date"
ne signifie rien du tout d'autre qu'un symbole.
C'est l'APPLICATION qui lui donne ce sens.
La specs d'un provider "qui contient" une date
peut éventuellement dire qu'alors elle doit avoir le PGI 0 mais
c'est HORS du champs de TSP lui-même et cela
me semble trop contraignant.
2) On peut très bien coder un provider qui n'est pas
"réellement" cyclique
et dans ce cas la notion de date...
C'est hors sujet ici mais on peut très bien coder un provider
qui annonce fonctionner à 64Hz alors qu'il est en fait complètement
acyclique. C'est TRES pratique, on pourrait détailler ça dans
une présentation spécifique.
3) CONTRAIREMENT à ce que j'ai dit initialement l'implémentation
ACTUELLE ordonne les samples dans l'ordre de la request_sample
(en respectant les periodes et phases) en particulier si on demande
le symbole "date" en premier dans la liste avec la period 1
ce symbole sera TOUJOURS en premier dans tous les groupes
si il y en a plusieurs.
Quoiqu'il en soit ce qui reste vrai (et je m'excuse d'avoir semé
la confusion sur ce sujet avec mon erreur sur l'implem' actuelle)
c'est que ce n'est pas un pré-requis de SPECIFICATIONS
mais un CHOIX d'implémentation donc je suggèrerais de ne pas
UTILISER cette propriété, car elle peut changer si on décide
de changer la chose.
Ce qui pourrait éventuellement être fait c'est d'ajouter à TSP une API qui
garantit ce comportement. Cette API "de plus haut niveau"
fera (ou pas) le ré-ordonnancement de la date en premier
si l'API (actuelle) de plus bas niveau ne le fait pas déjà.
Vu les débats animés (et intéressants) sur le sujet je vous promets
une bafouille écrite et concise (enfin je vais essayer) sur le sujet
théorie des groupes, spécs TSP dans ce domaine et propriétés
de l'implémentation actuelle.
De façon à identifier simplement ce qui est du domaine
des specs et ce qui est du domaine du choix d'implem'.
Histoire de tempérer l'urgence de l'impact perfo de ce qui
pourrait apparaître comme un problème je tiens juste à rappeler
que la valeur par défaut sur pas mal d'unix (Linux en premier)
d'un buffer socket est 64Ko, donc une appli. qui ouvre 1 seule
socket associe déjà implicitement un buffer de 64Ko.
(on peut le retailler néanmoins).
Donc TSP ne me semble pas pire que l'API socket dans ce domaine :))
Avec une date en PGI 0 l'implémentation actuelle de TSP
possède les propriétés que recherche Virginie donc ça
ne pose pas de pb AUJOURD'HUI.
Je donnais juste un conseil "dans l'absolu", car je trouve dommage
de mettre "trop de contrainte" "a priori".
Si vous me montrer que la bufferisation est un REEL tueur
de perfo alors OK on mettra la contrainte, mais l'accepter "a priori"
dans TSP me parait déraisonnable, néanmoins ma voix compte pour 1.
Mon avis est aussi que si nous devions changer qqchose à
l'implémenation actuelle
de TSP qui ait un impact dans ce domaine et bien nous
créerons soit une branche de maintenance gardant le comportement
actuel soit une API nouvelle/ancienne pour garder la compatibilité.
--
Erk