RE: RE : [Tsp-devel] Ptit debriefing necessaire

[Eric.NOULARD]

Sur le fond je suis 100% d'accord,
1 processus a chaque requete ca craint :))

Et c'est ce que faisait les bons vieux serveurs
avant l'existence des thread mais bon...

D'un autre cote peut-etre faudrait-il demander
au developpeur du serveur XML-RPC pourquoi il a fait ca,
y'a peut-etre une raison.

Vis-a-vis de l'elegance SHM c'est pas un souci vu
que le reste du code ne devrait pas voir la difference
un pointeur en vaut bien un autre ...

Ce qui peut etre penible c'est de melanger
pthread_xxx et IPC sysV notamment je suis pas
sur qu'on puisse mettre un semaphore POSIX dans
un SHM sysV...



-----Original Message-----
From:   address@hidden on behalf of TSP
Sent:   Mon 3/21/2005 3:59 PM
To:     'address@hidden'
Cc:    
Subject:        RE : [Tsp-devel] Ptit debriefing necessaire
Cela ne risque-t-il pas d'être un peu lourd, tout en shm et un processus à
chaque requete ?
Je ne sais pas si la modif de xmlrpc en thread est
- facile
- perenne
- fiable
Mais au moins, ce serait + élégant.

Y++

>-----Original Message-----
>From: Frederik Deweerdt [mailto:address@hidden]
>Sent: Monday, March 21, 2005 8:37 AM
>To: Devel TSP
>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_b
>y_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
>