Re: [Tsp-devel] Ptit debriefing necessaire

[Eric NOULARD]

Le lundi 14 mars 2005 à 20:20 +0100, Frederik Deweerdt a écrit :
> Avé
> 
> Je suis en train de bosser sur l'ajout d'XMLRPC comme transport pour canal
> des commandes.

Ca c'est cool :))
Quelque effervescence TSP en ce moment.

> La partie communication client <-> serveur semble marcher sans trop de 
> problème
> le seul problème reste le passage de type de données compliqués (ce n'est pas
> très élégant).
> J'ai un problème avec le cycle de vie TSP_provider_rqh_manager_* et son
> interaction avec les status (running, idle etc...)
> J'ai la sortie suivante avec le tsp_stub_server:
> 
>     i/o||tsp_provider_init.c##TSP_provider_init##50: -->IN
>     i/o||tsp_provider.c##TSP_cmd_line_parser##87: -->IN
>    Info||tsp_provider.c##TSP_cmd_line_parser##211: No GLU stream init 
> provided on command line
>     i/o||tsp_provider.c##TSP_cmd_line_parser##221: -->OUT
>     i/o||tsp_request.c##TSP_provider_rqh_manager_init##142: -->IN
>     i/o||tsp_request.c##TSP_provider_rqh_manager_init##167: -->OUT
>     i/o||tsp_provider_init.c##TSP_provider_init##60: -->OUT
>     i/o||tsp_provider_init.c##TSP_provider_run##69: -->IN
>     i/o||tsp_request.c##TSP_provider_rqh_manager_install##110: -->IN
>     i/o||tsp_request.c##TSP_provider_rqh_manager_install##133: -->OUT
>     i/o||tsp_request.c##TSP_provider_rqh_manager_refresh##183: -->IN
>     i/o||tsp_server.c##TSP_rpc_request_run##390: -->IN
>     i/o||tsp_request.c##TSP_provider_rqh_manager_end##250: -->IN
>    Info||tsp_request.c##TSP_provider_rqh_manager_refresh##222: Request 
> handler # 0 started with URL 
>     i/o||tsp_request.c##TSP_provider_rqh_manager_refresh##235: -->OUT
>     i/o||tsp_provider_init.c##TSP_provider_run##104: -->OUT
>     i/o||tsp_request.c##TSP_provider_rqh_manager_get_nb_running##67: -->IN
> FIXME: find a way to stop the abyss server
>     i/o||tsp_request.c##TSP_provider_rqh_manager_get_nb_running##73: -->OUT
>     i/o||tsp_request.c##TSP_provider_rqh_manager_end##280: -->OUT
> 
> Le FIXME est ce que j'ai mis dans TSP_rpc_stop, comme se fait-il que cette 
> fonction 
> se fasse appeler (si j'ai bien compris c'est un atexit() qui provoque 
> l'appel)?
> Je sens qu'un thread trifouille dans mon dos pour fermer la requete, mais 
> l'api
> reste un peu floue pour moi. Un eclaireur de lenterne siouplé?

En fait je vais te faire une réponse un peu "théorique" vu qu'après mon
implémentation initiale fortement alpha Robert est passé par là pour 
rétablir les choses propres :))

En théorie 4 fonctions par request_handler regroupée dans une structure
(TSP_provider_request_handler_t), c'est une approche qui se veut
 "C objet"
donc les fonctions:

  config
  run
  stop
  url

Les handler de requêtes sont aujourd'hui installés statiquement
dans TSP_provider_run:
>>> tsp_provider_init.c <<<
     /* build and install default request handler (RPC) */
      TSP_provider_rqh_manager_install(0,TSP_rpc_request);


Les handlers installés sont ensuite "pris en charge"
 par le request manager qui va se charger d'appeler le fonctions
config, run, stop, url et ceci dans la fonction

TSP_provider_rqh_manager_refresh

qui est 'la machine à états' des request_handler installée.

Si il est IDLE alors on appelle config 
puis pthread_create(run) si le config a réussi
y'a un petit touillage de tempo pour attendre le démarrage effectif
du thread.

Tu noteras au passage que nous avons postulé que la fonction run ne
se terminerait JAMAIS sauf si on appelle 'stop'.

Ce qui arrivera par un appel à TSP_provider_rqh_manager_end
(lui même appelé dans TSP_provider_end).

Ce qui me parait louche dans tes traces ce sont les appels
à TSP_provider_rqh_manager_end , peut-être est-ce par que ta
fonction 'run' se termine après le traitement d'1 requête?

TSP manque cruellement de doc et moi cruellement de temps :))
Heureusement que vous êtes tous là :))

Eric