Re: RE : RE : RE : [Tsp-devel] Ordr e d'arrivée des samples d'un groupe

[Eric Noulard]

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