Re: [Tsp-devel] Personnalisation d'un provider TSP

[Eric Noulard]

Le 16 octobre 2008 10:11, TSP <address@hidden> a écrit :

>>Une autre question, l'utilisation de :
>>TSP_datapool_get_reverse_list(cthis->datapool,&nb_symbols,
>>&ptr_index);
>>retourne le nombre et la liste des pgi des variables demandées
>>par les clients mais ces données ne sont pas mise à jour lors
>>des deconnexions de ceux-ci. Est-ce normal ?
>
> Oui, c'était un choix de simplification à l'époque. La problématique était la 
> suivante:
> - Un provider propose plus de 1 million de param à sampler.
> - Un client vient et en demande 100.
> La simple boucle pour regarder l'update des million de param faisait ramer le 
> provider.
> On a donc crée ce tableau, qui represente la liste des param voulus par 
> l'ensemble des clients. En se disant que si ils ont été demandé une fois, ils 
> risquent de l'etre encore dans le futur. Puis cela peremettait de le coder 
> simplement avec un booléan, plutot qu'avec une table d'index par clients.

> Je ne suis pas contre que tu modifies le code pour gérer la mise à jour sur 
> déconnexion, mais cela me semble inutile vu le besoin. Et attention à ne pas 
> enlever un symbole abandonné par la fin de ton client, mais encore nécessaire 
> pour un autre.

En fait je pense que l'extension pourrait être intéressante SI
on a des consumers qui demandent des symboles très variés
ET ne reste pas connecté longtemps. Ce qui comme l'indique Yves n'a
jamais été le cas pour l'instant.

Sinon une solution pourrait être
au lieu de gérer un tableau d'index (PGI) des symboles demandés de gérer
côté provider un tableau contenant un couple (PGI, askedCount)
(ou un deuxieme tableau askedCount de la même taille que reverse_index)

askedCount serait le nombre de consumer demandant le symbole
quand il tombe à zéro on recalcule le tableau.

On doit pouvoir avoir un algo dont la complexité est fonction
du nombre de symboles _demandés_ et pas du nombre de symboles
_disponibles_. Ce qui par hypothèse dans TSP devrait rester
"raisonnablement petit".

Pour des besoins de compatibilité on peut garder le tableau d'index actuel
(reverse_index) et le mettre à jour à chaque déconnexion en utilisant
l'autre tableau
qui a été mis à jour préalablement.

Ca fait un peu de surcharge pour le provider à la deconnexion.

Next time we should try to say that in english in order to involve
our english speaking contributors who may be interested in the subject :-)

-- 
Erk