[Tsp-devel] Qqs interrogations

[PAGNOT, Robert]

Salut à tous,

 

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. 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 ...

• 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()" ...

A vous,

 

    Robert

 

important_notice.txt
Description: Text document