[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Tsp-devel] Qqs interrogations
From: |
TSP |
Subject: |
RE: [Tsp-devel] Qqs interrogations |
Date: |
Fri, 17 Sep 2004 10:56:09 +0200 |
D'accord pour les n iterations pour trouver un port RPC de libre, mais
comme le dit si bien notre "Mètre à panser" Eric, il faut le faire dans la
couche specifique RPC.
Pour
le TSP_provider_close, je vais voir ce que je peux faire, mais l'idée me va (Je
suis TOUJOURS d'accord avec les API symetriques du genre open/close, start/stop,
sucre/sel, bit/couilles, bush/ben laden, ...)
Y++
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