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

[TSP]

Moi m'excuser mais moi neuneu :
Pourquoi faire de l'IPC ou du SHM, si fred dit qu'il est faisable de passer
le xml-rpc en thread ? 

Je peux comprendre la nostalgie de programmation des messages queues, mais
j'ai toujours eu un faible pour la simplicité du TOUT partagé automatique
des threads, surtout corrélé avec leur super perfs en kernel 2.6.

Le seul argument valable (a mon avis) c'est la remarque de Fred demandant si
les structures n'étant pas protégées, on ne risquait pas d'avoir un conflit
atomique en cas de multiserveur (mais je pensais que Eric avait déjà fait
joujou avec un double RPC)

Ensuite il reste à voir pour corba. Si le mécanisme est similaire à xml-rpc
(je fork chaque requête) il faudra peut-être faire du SHM, mais sinon je
persiste et signe : VIVA EL THREADS, VIVA LA MUERTE ! SHM no passaran....

Y++


>-----Original Message-----
>From: Eric NOULARD [mailto:address@hidden 
>Sent: Tuesday, March 22, 2005 12:16 AM
>To: Devel TSP
>Subject: Re: RE : [Tsp-devel] Ptit debriefing necessaire
>
>
>En y réfléchissant mieux je pense que ce serait au handler de requête
>XML-RPC de "faire ce qu'il faut avec ses fils" pour venir renseigner
>les structures actuelles.
>
>En gros c'est au XML-RPC handler de se gérer sa SHM.
>Ce qui n'exclut pas de proposer un mini-wrapper pour ça dans
>tsp/util ou tsp/core/ipc.
>
>Et a y réfléchir c'est une méthode bien bien louche de faire
>mourir le père une fois qu'il a engendré.
>On est plus au moyen âge :))
>Non sérieusement le père devrait survivre à son fils qui meurt
>en fin de gestion de requête charge au père de collecter les
>info que son fils aura bien voulu déposer dans une IPC
>par exemple une msg queue, plutôt qu'un SHM ce qui permet de
>sérialiser gentiment les mises à jour et d'éviter d'impacter
>les serveurs multi-thread qui n'ont pas besoin de SHM.
>
>Reste que cette message queue doit-être lu par un thread du process
>provider, normalement celui du 'run' sauf que si celui-ci se termine
>je vois pas bien qui va collecter les messages.
>
>Votre avis?
>
>
>Le lundi 21 mars 2005 à 15:59 +0100, TSP a écrit :
>> 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
>> >
>> _______________________________________________ Tsp-devel 
>mailing list address@hidden 
>http://lists.nongnu.org/mailman/listinfo/tsp-devel
>
>
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/tsp-devel
>

important_notice.txt
Description: Text document