RE: [Tsp-devel] Qqs interrogations

[Eric.NOULARD]

> Je vous fait part de deux questions sur les providers qui me torturent
> l'esprit ...
>
> *     TSP_provider_init & port RPC : cela nous arrive souvent d'avoir
> plusieurs providers de nature différente qui essayent de tourner sur la même
> machine (un stub, un res_reader, un TL1 sample server, un G-SIF, etc ...),
> or ils essayent presque tous d'utiliser le provider_num par default (= 0)
> d'où des RPC_clnt_create failed systématiques.

>*     
>
>       J'ai appliqué une stratégie pour le G-SIF qui consiste à incrémenter
>le provider_num (par les TSP-args) jusqu'à la réussite de TSP_provider_init.

EUh là je me mefierais de ça, il faut quand même mettre une limite
au ++ car dernièrement j'ai eu des echec du à un daemin portmap
pas lancé :))

> Je recupère ainsi le provider_num que je publie (par des moyens quelconques
> : SHM, /tmp, SNMP, ...) à mes futurs clients. C'est lourd en codage, car il
> faut touiller les args de l'appel TSP_provider_init.
> *    

>       Pourquoi ne pas gérer cette approche en interne du TSP_provider_init
>(lorsque aucun provider_num n'est founi par les args) et retourner à
>l'appelant le provider_num ? Sauf coup-de-gueule, ou contre-indication,
>avant mercredi 22/09 j'implemente cela ...

En fait je suis contre ce touillage dans (le core) TSP, car c'est
 typiquement c'est un pb lié à RPC qui serait différent avec un lien de commande CORBA, XML-RPC, ...

Je sais que c'est pas[rtiellement] implémenté mais qd même...

En tout les cas chaque fournisseur de lien de commande (Request Handler
cf core/ctrl/tsp_request.[c|h]
doit fournir une méthode (fonction) pour se configurer  correctement
quitte à chercher un progid libre ou un port ou etc...
c'est donc à la fonction de config du RQH RPC de faire le boulot.
Ce qui m'échappe c'est que j'appelais cette fonction dans le
TSP_provider_run et pas TSP_provider_init mais ...

...bon maintenant il faut que je (re)discute des RQH avec Robert
car ça fait un moment que je l'ai fait et ...
pas utilisé beaucoup (1 test avec 2 serveurs RPC sur le même provider).


>*     
>
>       Arrêt propre d'un provider PASSIVE : maintenant que l'on fait du
>PUSH/COMMIT, l'appellant doit pouvoir faire un exit propre, en attendant que
>tous les threads du provider aient fini leur boulot. Dans le cas du
>tsp_res_reader (mono-fichier, mono-client), par exemple, à la fin du
>fichier, on genère un GLU_GET_EOF qui a pour effet de flusher les clients.
>Une fois que tout est finit, côté provider, on doit pouvoir quitter le
>process provider, la paix dans l'âme, en invoquant avant exit un
>TSP_provider_close() qui attend le flush global et ferme les threads
>proprement.

>*     
>
>       Quelqu'un pourrait-il s'en charger ? Ou est-ce encore une connerie à
>moi ? Genre "sleep(1); exit()" ...

Ben là je serais bien pour ajouter un tsp_ctl (TSP control) à la manière
de ioctl/fcntl etc... qui implémenterais des synchros consumer ou provider
du genre tsp_ctl(WAIT_TSP_PROVIDER_START)
tsp_ctl(WAIT_TSP_PROVIDER_STOP) et d'autre cochonneries.

Sinon ben j'ai pas le temps de faire ça pour l'instant :((

Je suis en cours sur un consumer qui crachera un fichier ascii tabulé
(besoin immédiat) et pourquoi pas le reader qui va avec d'ailleurs :))
l'intérêt du truc c'est qu'on peut attacher facilement un gnuplot
(qui tourne en boucle cf le reread de gnuplot)
 sur le fichier craché par le consumer
[optionnellement limité en taille (au bout de N lignes je ré-écris au début)]

Du coup on a des courbes gnuplot pour TSP pas cher
(c'est un leitmotiv de mon client du moment)


Je commit ça dès que c'est près.

Eric