RE: [Tsp-devel] Provider et jeune début ant

[TSP]

Ah qu'il est beau de voir un regard neuf sur this (in)famous code de TsP.

La philo des thread TSP est assez complexe, et de plus elle s'imagine
maîtriser le sequencement de l'empilage des données. Si je simplifie :
- Le TSP_provider_run crée 2+N threads : 
        - Le thread pour écouter les commandes RPC.
        - Le thread data pool qui PULL les données par le get_next_item
        - Les N threads pour envoyer les données à chaque client.
- Dans le stub d'exemple, il y a en + le Glu_thread qui crée les données
pour les empiler dans un ringbuffer pour se faire défiler (avec
préliminaires) par le thread datapool.

Je pense qu'il serait faisable (souhaitable) de simplifier un peu cette API.
Si on imagine une philo en PUSH pour le datapool, cela correspondrait à ton
besoin et simplifierait sans doute les problème de synchro. L'idée est de
faire disparaître le Glu thread, et laisser un main utilisateur appeler
cycliquement une fonction pour empiler de nouvelles donnés dans le datapool.


On passerait donc de N+3 thread (RPC+DataPool+GLU et clients) à N+1 (RPC et
clients). Pour cela il faudrait modifier un peu TSP. 
- un TSP_provider_run qui ne soit est bloquant (ou avec un paramètre pour
décider le bloquant/non bloquant)
- Ne pas créer le thread datapool dans TSP si non bloquant.
- Offrir une fonction TSP_put_next_item (symétrique du get). Elle empile les
donnés comme le fait le code appelant le get, et signal à tous les clients
quand le time tag change et qu'il faut publier les datas.


A ton main il te faudra donc ensuite rajouter plusieurs choses :
- un TSP_provider_init pour préparer les objets TSP
- un TSP_provider_run avec param non bloquant
- Dans ta boucle, appeler le TSP_push_next_item à chaque nouvelle data.


Voila, j'attends les commentaires des autres gourous du TSP, et on voit qui
s'y colle.

Y++

> -----Original Message-----
> From: sebastien guilbaud [mailto:address@hidden
> Sent: Monday, June 07, 2004 10:53 AM
> To: ML TSP
> Subject: [Tsp-devel] Provider et jeune débutant
> 
> 
> Salut a tous,
> En temps que nouveau sur la liste, (du - en terme de 
> contributions) j'ai 
> une
> question pour les spécialistes du coté provider :
> Voilà - plouf plouf - Je m'interroge sur la possibilité 
> d'interfacer en bon
> utilisateur que je suis un programme ultra simple genre ;
> 
> main (blabla) {
> double toto;
> while (1) toto++;
> usleep (qqch);
> exit (1);}
> 
> au serveur de données qu'est le TSP. Coté consommateur je 
> pourrais alors 
> lancer ma belle IHM et voir une belle ligne qui grimpe avec le temps 
> (moyennant la prise en compte du temps dans mon main mais 
> j'ai fait court)
> 
> Jusqu'à présent, la seule chose présente dans le code (stub 
> server) est 
> un thread, (GLU_thread) partie intégrante du TSP qui délivre 
> des données 
> calculées via une libcalc. Il ne s'agit donc pas d'un process 
> indépendant mais d'un calcul de données initié et piloté par 
> le TSP lui 
> même.
> 
> Comment dois je m'y prendre pour fair la colle entre
> 1- mon main
> 2- le TSP qui crée a RPC connection, le datapool etc ect ....
> 
> Sont ce alors 2 process différents ? (non threadés)
> 
> Voilà, par ailleurs dans le stub server, certaines fonctions 
> de GLU ne 
> font pas grand chose. Je pense a GLU_get_instance() (je crois) dont 
> l'implémentation me parait pour le moins minimale (une chaine 
> d'erreur 
> vide retournée tout le temps ). A quoi sert il donc ?
> 
> Merci de vos idées.
> 
> Je précise également entre autres choses que je rédige 
> actuellement une 
> doc pour la prise en main du TSP pour les béotiens tels que moi. Je 
> pense pouvoir vous délivrer un premier draft avant l'été .....
> 
> A+
> Seb
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>

important_notice.txt
Description: Text document