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

[Eric NOULARD]

Le mardi 22 mars 2005 à 09:53 +0100, TSP a écrit :
> 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 ? 

Because quand on intègre un bidule extérieur c'est toujours plus simple
de faire (et maintenir) les modifs chez toi plutôt que chez les
autres :))

Sur le fond je suis d'accord tu as raison VIVA EL 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.

Re-d'accord.

> 
> 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)

J'ai effectivement joué avec 2 serveurs RPC sans souci 
mais bon soyons honnêtes je n'ai pas essayé d'avoir 
EFFECTIVEMENT 2 requêtes RPC REELLEMENT concurrentes...

Mais j'ai pris toutes les précautions théoriques pour qu'il n'y ait
pas de pb,
cf mon mail précédent qui a dû croiser le tien :))

> 
> 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....

Je pense que le mieux serait peut-être de demander au type qui a fait
le serveur XML-RPC pourquoi il a préféré forker plutôt que de
pthread_create?

Si il a de bonne raisons on (i.e. Fred :)) peut peut-être faire un
effort sinon ben on patch pour passer à un modèle thread.

A ce propos Fred, quel est le serveur XML-RPC que tu as choisi?
Une URL peut-être?

Eric
> 
> 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
> >
> _______________________________________________ Tsp-devel mailing list 
> address@hidden http://lists.nongnu.org/mailman/listinfo/tsp-devel