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

[Erk]

Le 19/04/06, TSP<address@hidden> a écrit :
>
>>> 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é)
>Il y a un vilain hack dans TSP_provider_request_sample (de
tsp_provider.c), qui sur >création du premier client, appelle le
GLU_start, qui lui créait le GLU_Thread du >provider, et commençait à
envoyer les données. Quand on a inversé la philo d'appel de >TSP (Le
GLU provider fait lui même le max d'appel vers la lib tsp_core), et
supprimé les >2 threads inutiles ainsi que le RINGBUF entre GLU et
datapool (voir la nouvelle fonction >push_next_item), on a simplifié
cela.

Et c'est bien, d'avoir simplifié et enlevé un RINGBUF.

J'ai moi même forcé le démarrage du thread GLU dès le TSP_provider_run
sauf que cette approche là ne marche pas avec un GLU PASSIVE,
qui ne devraient démarrer qu'au moment du request_sample_init


> >> 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.
>
> Je pense qu'il faudrait essayer de faire disparaître le coté passif / actif 
> (Mais discrètement achever la bête sans se faire taper dessus par la SPA.

Je ne suis pas tout à fait du même avis :))
Comment faire un provider fichier multi-consumer ?
Voire un provider "multi(fichier" puisque le consumer
peut passer des arguments (argc/argv) dans la request_open
justement pour ça (il me semble).


> Quand je regarde le code d'un provider, il fait une boucle sur tous les 
> symboles à distribuer avec un TSP_datapool_push_next_item par symbole, et un 
> TSP_datapool_push_commit à la fin pour dire que le jeu de données est 
> cohérent. Il suffit d'avoir une feature à la connexion, qui dit si oui ou non 
> le TSP_datapool_push_commit est bloquant ou pas. Dans le cas des actifs, il 
> ne l'est pas, et c'est aux clients à se dépêcher de suivre le temps réel. 
> Dans le cas du passif, le commit se bloque jusqu'a que le serveur ait mis 
> dans la socket la copie du datapool (Pas la peine d'avoir de buffer, c'est le 
> fichier .res ou autre qui sert de mémoire).

Je suis tout à fait d'accord avec ça mais comment gère-t-on le fait que
+ieurs consumers peuvent se connecter au même provider fichier?

(sans en être forcément au même endroit dans le fichier...
 voire sans lire le même fichier)

Aujourd'hui il y a une instance de GLU par session (i.e. consumer connecté)
ce que je trouve très bien (d'où l'intérêt du get_instance)
seulement si il n'y a qu'UN SEUL DATAPOOL GLOBAL ça ne marche pas...

D'où le besoin du datapool local, sur lequel effectivement
le "commit" pourra être bloquant.

Yves qu'est-ce qui te donne envie de tuer le PASSIVE GLU?
L'idée me parais bonne? Qu'est-ce qui te gêne?
Je trouve qu'on perdrait beaucoup à ne pas avoir des providers fichiers non?

--
Erk