RE: [Tsp-devel] Ptit debriefing necessaire

[Eric.NOULARD]

Suite a une discussion avec Fred nous n'avons effectivement
pas envisage qu'un request handler puisse forker
a chaque requete :))

Je suis pour la solution 2) --> memoire partagee
[plus un petit mail au dev du serveur XML-RPC
 car forker c'est pas bien :)) ]

je pense meme que pour les shm internes a TSP on
pourrait utiliser le BB afin de se simplifier le
portage si besoin, on aurait que le BB a porter
ce qui est assez simple.

Toutefois il serait souhaitable d'utiliser
uniquement les fonctions de bb_core.h et bb_utils.h.

Sinon on peut aussi avoir une approche 'inversee'
qui genererait moins de dependance qui serait d'ecrire
un 'tsp_shm.h' 'tsp_sem.h' et 'tsp_msg.h' qui
permette d'utiliser DANS le coeur TSP des shm,semaphore
et autre messages queue
(pourquoi pas 'tsp_ipc.h' d'ailleurs) on ecrit une poignee
de wrapper permettant de manipuler des IPC (POSIX, sysV, VxWorks...)
le coeur TSP s'appuie dessus et des que c'est pret ben je
fait les modifs BB pour qu'il s'appuit dessus?

Vos avis?

Mon idee est de

 - minimiser les dependances,
 - faciliter le portage des primitives IPCs
 
Eric

-----Original Message-----
From:   address@hidden on behalf of Frederik Deweerdt
Sent:   Mon 3/21/2005 8:36 AM
To:     Devel TSP
Cc:    
Subject:        Re: [Tsp-devel] Ptit debriefing necessaire
Le 14/03/05 22:47 +0100, Eric NOULARD écrivit:
> Le lundi 14 mars 2005 à 20:20 +0100, Frederik Deweerdt a écrit :
> 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?
Ok, problème, réglé: en fait le serveur HTTP qui dispache les requêtes fait
un fork avec :
fils -> RunServer() //Serveur HTTP
pere -> exit(0)

Le exit(0) déclenchait l'execution des atexit() et lancait le
TSP_provider_rqh_manager_end.

J'ai résolu le problème de la manière suivante:

static clean_exit() {
  _exit(0);
}

static void TSP_rpc_run(TSP_rpc_request_config_t *config)
{
        atexit(clean_exit);
        ...
}

Mon serveur tourne donc correctement, mais voilà un autre problème:
chaque requête xml est traitée par un process différent, ce qui fait que
les données de session (X_session) sont perdues lors d'un nouvel appel:

    i/o||tsp_server.c##tsp_request_open_xmlrpc##100: -->IN
    i/o||tsp_provider.c##TSP_provider_request_open##247: -->IN
  debug||tsp_provider.c##TSP_provider_request_open##265: No custom args from consumer
  debug||tsp_session.c##TSP_add_session##229: I've found room in X_session_t for the new session. Id in X_session_t is 0, pid is : 11256
   Info||tsp_session.c##TSP_add_session##254: New consumer connected : channel_id=0, X_session_nb is : 1
    i/o||tsp_provider.c##TSP_provider_request_open##299: -->OUT
    i/o||tsp_server.c##tsp_request_open_xmlrpc##109: -->OUT
    i/o||tsp_server.c##tsp_request_information_xmlrpc##180: -->IN
  ERROR||tsp_session.c##TSP_get_session##127: No session found for channel_id=0, X_session_nb is: 0, pid is 11257
  ERROR||tsp_session.c##TSP_session_get_sample_symbol_info_list_by_channel##331: Unable to get session for channel_id=0
  ERROR||tsp_provider.c##TSP_provider_request_information##357: Function TSP_session_get_sample_symbol_info_list_by_channel failed
    i/o||tsp_provider.c##TSP_provider_request_information##367: -->OUT
    i/o||tsp_server.c##tsp_request_information_xmlrpc##187: -->OUT

Notez comment varie X_session_nb et le pid...

Les solutions que je vois seraient:
- modifier xmlrpc pour qu'il utilise des threads
- mettre toutes les données de session en mémoire partagée

J'opterais bien pour la seconde mais peut-être avez vous des suggestions?
A+
Fred
--
o----------------------------------------------o
| http://open-news.net : l'info alternative    |
| Tech - Sciences - Politique - International  |
o----------------------------------------------o


_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel