Re: [Tsp-devel] GLU ACTIVE ou pASSIVE et "local_datapool'

[Stephane Galles]

Selon address@hidden:

> Cher Amis,
>
> Il semblerait qu'un certains nombres de nos modifs
> conjointes (j'en prends ma part) aient un peu "cassé"
> le foncitonnement normal des GLU "passive"....
>
> Est-ce que Stef GCaribou pourrait nous rafraichir la mémoire
> sur sa conception des GLU ACTIVE et PASSIVE et leur
> relation avec les datapool locaux et globlaux
> ainsi que comment "devait" fonctionner la chose.

Je vais essayer de te donner quelques infos de mémoire,
pour plus de détail il faudrait que je regarde le code.

Mais le principe est de pouvoir lire des choses comme des
fichiers, et comme rien ne presse dans ce cas, de donner
plus de controle au consumer.

>
> 1) quand est-ce qu'un datapool passive commence à envoyer
>    ses sample?
L'idée est qu'il n'y a pas de thread qui pousse les données.
Le rythme de lecture est celui du consumer (c'est le consumer
qui "tire" les données et qui donne le rythme au GLU).
Dans ce cas, le GLU attend que la socket se vide avant d'ajouter
des données (je ne sais plus comment ce truc était implémenté)


> 2) Bloque-t-il si le consumer ne consomme pas?
cf 1

> 3) Est-ce que chaque session ouverte sur un GLU passive est indépendante?
Oui, un context était passé au GLU pour que chaque consumer puisse
pointer à un endroit différent. De mémoire c'était à cela que servait
les datapool locaux (il sont locaux à chaque consumer, le global etait
utilisé dans le mode "active")

>
> Est-ce que l'implémentation qui marchait de l'époque avait des
> limitations?

Pas que je sache.
(En fait si : elle n'était pas en Ruby  :O )

Si ma mémoire est bonne le mode PASSIVE était une fausse bonne idée qu'on
avait eu avec Yves, et je crois me rappeler qu'on s'en ait mordu les doigts
parceque cela avait compliqué beaucoup le code. Hum il me semble que Yves
voulait tuer ce mode, plus ou moins, mais sans le faire souffrir. On est pas
des bêtes.

Yves ? Je crois me rappeler d'un de tes message en rapport avec les datapool
globaux/locaux. A tu commencé à zigouiller l'animal ?


>
> Bon évidemment cela exhibe un peu de négligence de nos QA procédures...
> mais ça va s'arranger.
>
> Merci d'avance à tous d'éclairer ma lanterne.
>
> ---
> Eric Noulard - Software Architect
> BT Consulting & Systems Integration
> tel: (+33) (0)534 604970
> mob: (+33) (0)607 948100
> web: www.bt.com/consulting
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>


--