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

[TSP]

Voir mes réponses dans le texte.

>-----Original Message-----
>From: Stephane Galles [mailto:address@hidden
>Sent: Tuesday, April 18, 2006 6:42 PM
>To: Transport Sample Protocol development list
>Subject: Re: [Tsp-devel] GLU ACTIVE ou pASSIVE et "local_datapool'
>
>
>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"....
Tu ne seras pas le premier :=)
>>
>> 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é)
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.

>
>> 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?
Même il marchait si plusieurs clients passifs voulaient defiler le même 
fichier, mais pas en même temps....
J'ai peur qu'on ait un peu cassé cette partie là...

>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.
C'est clair, c'etait vraiment une mauvaise idée, et je ne peux pour une fois 
m'en prendre qu'à moi (Je ne peux même pas accuser Robert, c'est vraiment trop 
injuste ....)

>Yves ? Je crois me rappeler d'un de tes message en rapport
>avec les datapool
>globaux/locaux. A tu commencé à zigouiller l'animal ?
Oui, voir premiere remarque.
>
>>
>> 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.
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).

Y++


>> ---
>> 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
>>
>
>
>--
>
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/tsp-devel
>

---------------------------------------------------------

CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT 
ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.

SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, 
MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER 
ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, 
VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE 
COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.



This email is for information only and will not bind EADS Astrium SAS in any 
contract or obligation, nor its subsidiaries.

If you have received it in error, please notify the sender by return email. If 
you are not the addressee of this email, you must not use, keep, disseminate, 
copy, print or otherwise deal with it.

---------------------------------------------------------